Closed apconole closed 3 years ago
@hreinecke @sregister @penguin359 @kloczek @topuri @srivatsabhat @gonzoleeman
I'm not sure you have to be so diligent, but that's your call. When I do a new release for open-iscsi, I just wait for a period of relative quiet, then I announce I plan to tag a new version, wait a day or two, then do it if no objections.
If there is something "invalid" in the code (existing bugs not yet discovered or reported), then can be fixed as found. After all, said defects, if they exist, already impact the latest code.
If you branch, you have to either freeze the master branch, or if you allow fixes on master while you're validating, you have to merge and test again?
Also, that way, you avoid having an extra public branch. Just my $.02
I've pushed a new branch (branch-1.1) for backporting any changes needed. Additionally, I've updated the Changelog in master to reflect the changes over the last few years.
I would like to make a release soon. It has been ~5 years since a release has been made, and there are enough fixes accumulated to make a release. Additionally, it seems there are probably some features. As an example, c8e438d6 ("lldpad: Support DSCP selectors in APP TLV's") is probably worth mentioning.
My plan is to make a branch called 'branch-1.1' and start working through the process of validation. That way, future work can continue on 'master' branch, and we can backport any fixes (for 1.1.0, 1.1.1, etc). Are there objections to this approach? Is there a problem or better way that anyone sees?