Stig, It’s fine with me if we did this on purpose. But I think it makes it hard to follow semantic versioning (https://semver.org/ <https://semver.org/>). The semantic versioning is about:
Given a version number MAJOR.MINOR.PATCH, increment the: 1. MAJOR version when you make incompatible API changes, 2. MINOR version when you add functionality in a backwards compatible manner, and 3. PATCH version when you make backwards compatible bug fixes. To make discussion easier, I am taking 1.x release line as an example, although it’s already dropped and we are not going to do new release on 1.x. Currently we have 1.x (1.2.4-SNAPSHOT). We tend to merge commits to 1.x no matter if the commit is about new functionality or bug fixes. When we decide to do a release, we choose release version based on what’s already merged in. If there is no new functionality, the 1.x release will be 1.2.4. Then we update 1.x to 1.2.5-SNAPSHOT. But if there are new functionality we choose to release 1.3.0. But now we have to create 1.2.x-branch based on current 1.x, which already includes new functionalities. The result of it is that 1.2.x-branch includes not only bug fixes but also new functionalities, which breaks semantic versioning. There is no high risk for user to upgrade minor version. But the current way we are doing release doesn’t follow a clear versioning and we probably want to improve it. So I propose to stick with semantic versioning and release based on it. We released 2.0.0 and the current master branch is 2.0.1-SNAPSHOT. But we merged many new functionalities so we want to release 2.1.0 instead of 2.0.1. So we then create a 2.1.x-branch and release 2.1.0 from it. And switch master to 2.2.0-SNAPSHOT. After this, developers should only work on master branch and only bug fixes should be merged to 2.1.x-branch. We decided to release more frequently. At some point we will have too many branches to maintain. So I propose to drop some old release branches when we have a new release to keep a certain number of branches we maintain. For example, when we release 2.3.0, we can drop 2.1.x-branch and older branches. So we have master, 2.3.x-branch and 2.2.x-branch to maintain. As for 2.0.x-branch, I am fine with simply asking users to upgrade to 2.1.0 if there is an issue with 2.0.0 since there is no much risk involved. It’s also acceptable because we are kind of migrating from a loose semantic versioning to a strict one. > On Aug 9, 2019, at 7:35 AM, Stig Rohde Døssing <stigdoess...@gmail.com> wrote: > > Ethan, > > I think the idea has been that master is just the latest unreleased > version. The same goes for 1.x-branch, which is the latest unreleased 1.x > version (so 1.2.4 right now). I think we've been branching when necessary > rather than proactively, so e.g. when work requiring breaking changes to > 1.x started, the 1.x-branch was created and master became 2.0.0-SNAPSHOT. I > don't see an issue branching proactively by cutting a 2.1.x-branch > immediately, but I'm not sure it's necessary. It means that any change > going in 2.1.1 needs to be merged to master and also 2.1.x, instead of > master just being 2.1.x until we need to bump to 2.2.x. I see it as just > adding an extra unnecessary branch, because until master contains something > that should go in 2.2.x and not 2.1.x, the branches have the same contents. > Branching at the point where 2.2.x and 2.1.x would diverge makes more sense > IMO. > > I think at least for 2.1.0, I'd rather we ask users to upgrade to 2.1.0. > Otherwise, we need to create the 2.0.x branch from v2.0.0 and then go > cherry pick any changes that are already in master that should be in a > 2.0.1 release. Is there anything in 2.1.0 that's risky enough that we want > to put the effort of also doing a 2.0.1 in? > > Derek, > > I think the period of support so far has been based mostly around whether > anyone wants to put in the work to support old branches. We've been > dropping support once no one shows an interest in supporting the old > branches anymore. > > When you say a branch is LTS, I assume you mean we're promising to keep > putting out bugfix releases for that line? It seems like a fine idea, > assuming we limit ourselves to a couple of branches (maintaining 2.x and a > bunch of 1.x branches has been unpleasant in the past, but that probably > has more to do with slow release cadence). Regarding setting a date for > when a release line will no longer be supported, I'm not sure how easy it > is to set a date up front. For instance, I would have a hard time setting a > date for the end of 2.x support until there's a 3.x release on the horizon. > > If we're going to promise that a release line survives for a given amount > of time, I think we should do it at the major version level only, this also > seems to be what Traffic Server is doing. If we're following semver, > upgrading to minor versions should be safe, and I don't see the value of > promising to maintain e.g. both 2.0.x and 2.1.x for long periods. > > Where on the Traffic Server page do they list how long their release trains > survive? I only see dates of release, not how long e.g. 7.x is supposed to > receive support. > > Den fre. 9. aug. 2019 kl. 00.15 skrev Derek Dagit <da...@apache.org>: > >> What do we think about defining Long-Term Support branches with a fixed >> period of support? >> >> For example, we could say 2.0.x is an LTS release line with support >> ending no earlier than a certain calendar date. >> >> The date could be extended, and it might ultimately be governed by the >> timing of the subsequent release (e.g., 2.1.x or 3.0.x). Keeping things >> clear would imply semantic versioning as mentioned earlier >> (https://semver.org/). >> >> Apache Traffic Server does something like this, to name one project: >> >> https://trafficserver.apache.org/downloads >> >> Having a regular cadence of releases might also help make the process >> easier and help set expectations for users and devs. >> >> -- >> Derek >> >> On Thu, Aug 08, 2019 at 02:50:07PM -0500, Ethan Li wrote: >>> >>> Currently we don’t have a 2.0.x-branch and master is actually >> “2.0.1-SNAPSHOT”. >>> >>> So if we do a 2.1.0 release, we will create a 2.1.x-branch based on >> current master, release from there. And we change master to >> “2.2.0-SNAPSHOT”. >>> >>> But we will have one problem: we will lose 2.0.x release line. >>> >>> There are two things I can do: >>> >>> 1) create a 2.0.x-branch based on v2.0.0 tag. >>> >>> 2) ignore it. If there is an issue with 2.0.x release, ask users to >> upgrade to 2.1.0. >>> >>> I prefer 1) but not sure if it’s the right way to make things right. Or >> please let me know if I misunderstood something and it’s not an issue. >>> >>> Btw, I am seeing the same issue with 1.x-branch. We shouldn’t have >> 1.x-branch. Instead, we should have 1.2.x-branch. But this is not a problem >> since we will not release 1.3.x. >>> >>> Thanks, >>> Ethan >>> >>> >>>> On Aug 7, 2019, at 10:43 AM, Ethan Li <ethanopensou...@gmail.com> >> wrote: >>>> >>>> Yes thanks. >>>> >>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing < >> stigdoess...@gmail.com> wrote: >>>>> >>>>> Sounds great. Remember to add your key to >>>>> https://dist.apache.org/repos/dist/release/storm/KEYS, you should be >> able >>>>> to update it with an SVN client. See also >>>>> https://www.apache.org/dev/openpgp.html#update. >>>>> >>>>> Den ons. 7. aug. 2019 kl. 15.05 skrev Ethan Li < >> ethanopensou...@gmail.com>: >>>>> >>>>>> I got my pgp key signed by Bryan W. Call <bc...@apache.org <mailto: >>>>>> bc...@apache.org>> (Thanks to him). >>>>>> >>>>>> My pgp key: >>>>>> >> http://pgp.surfnet.nl/pks/lookup?op=vindex&fingerprint=on&search=0xA4A672F11B5050C8 >>>>>> < >>>>>> >> http://pgp.surfnet.nl/pks/lookup?op=vindex&fingerprint=on&search=0xA4A672F11B5050C8 >>>>>>> >>>>>> >>>>>> My understanding is that I am good to do release with this key now. >>>>>> >>>>>> >>>>>> Here is a list of PRs that we might want to include in the new >> release: >>>>>> >>>>>> https://github.com/apache/storm/pull/3098 < >>>>>> https://github.com/apache/storm/pull/3098> >>>>>> https://github.com/apache/storm/pull/3096 < >>>>>> https://github.com/apache/storm/pull/3096> >>>>>> https://github.com/apache/storm/pull/2878 < >>>>>> https://github.com/apache/storm/pull/2878> >>>>>> >>>>>> >>>>>> Please review if you get a chance. Thanks >>>>>> >>>>>> >>>>>> Ethan >>>>>> >>>>>> >>>>>> >>>>>>> On Aug 1, 2019, at 4:19 AM, Stig Rohde Døssing < >> stigdoess...@gmail.com> >>>>>> wrote: >>>>>>> >>>>>>> Thanks Ethan, yes 2.1.0 makes sense. >>>>>>> >>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li < >>>>>> ethanopensou...@gmail.com>: >>>>>>> >>>>>>>> It’s a good point. I will start a discussion thread for it. >>>>>>>> >>>>>>>> >>>>>>>> For the new release, I went through the list: >>>>>>>> >>>>>> >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1 >>>>>>>> < >>>>>>>> >>>>>> >> https://issues.apache.org/jira/issues/?jql=project%20=%20STORM%20AND%20fixVersion%20=%202.0.1 >>>>>>>>> >>>>>>>> >>>>>>>> We introduced some new functionalities, including >>>>>>>> https://issues.apache.org/jira/browse/STORM-2720 < >>>>>>>> https://issues.apache.org/jira/browse/STORM-2720> >>>>>>>> https://issues.apache.org/jira/browse/STORM-3412 < >>>>>>>> https://issues.apache.org/jira/browse/STORM-3412> >>>>>>>> https://issues.apache.org/jira/browse/STORM-3411 < >>>>>>>> https://issues.apache.org/jira/browse/STORM-3411> >>>>>>>> https://issues.apache.org/jira/browse/STORM-3442 < >>>>>>>> https://issues.apache.org/jira/browse/STORM-3442> >>>>>>>> https://issues.apache.org/jira/browse/STORM-3396 < >>>>>>>> https://issues.apache.org/jira/browse/STORM-3396> >>>>>>>> https://issues.apache.org/jira/browse/STORM-3392 < >>>>>>>> https://issues.apache.org/jira/browse/STORM-3392> >>>>>>>> https://issues.apache.org/jira/browse/STORM-3395 < >>>>>>>> https://issues.apache.org/jira/browse/STORM-3395> >>>>>>>> >>>>>>>> So I think we should release 2.1.0 rather than 2.0.1. >>>>>>>> >>>>>>>> There are a few pull requests we may want to review before the next >>>>>>>> release: >>>>>>>> >>>>>>>> https://github.com/apache/storm/pull/3094 < >>>>>>>> https://github.com/apache/storm/pull/3094> >>>>>>>> https://github.com/apache/storm/pull/2990 < >>>>>>>> https://github.com/apache/storm/pull/2990> >>>>>>>> https://github.com/apache/storm/pull/2878 < >>>>>>>> https://github.com/apache/storm/pull/2878> >>>>>>>> >>>>>>>> >>>>>>>> Thanks >>>>>>>> Ethan >>>>>>>> >>>>>>>> >>>>>>>>> On Jul 29, 2019, at 10:11 AM, Hugo Louro <hmclo...@gmail.com> >> wrote: >>>>>>>>> >>>>>>>>> +1 >>>>>>>>> >>>>>>>>> I think it would facilitate more frequent releases to summarize >> in a >>>>>> page >>>>>>>>> the testing that all contributors/committers do in anticipation >> of the >>>>>>>>> release, plus any "new" testing that may become relevant for the >> newer >>>>>>>>> releases. Doing so would make it easy to create a check form or or >>>>>> email >>>>>>>>> template that what we feel should be done to guarantee a stable >>>>>> release. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Hugo >>>>>>>>> >>>>>>>>> On Mon, Jul 29, 2019 at 7:15 AM Ethan Li < >> ethanopensou...@gmail.com> >>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Thanks Stig. I will look into it. >>>>>>>>>> >>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing < >>>>>>>> stigdoess...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>>> >>>>>>>>>>> I think ideally we've been trying for semver, but it's been >> pretty >>>>>>>> loose, >>>>>>>>>>> e.g. there were breaking changes in one of the 1.2.x releases >> for >>>>>>>>>>> storm-kafka-client. I don't know what rules we've actually been >>>>>> using, >>>>>>>> if >>>>>>>>>>> any. >>>>>>>>>>> >>>>>>>>>>> Semver for binary compatibility would probably be a good rule of >>>>>> thumb. >>>>>>>>>>> >>>>>>>>>>> Den fre. 26. jul. 2019 kl. 20.01 skrev Ethan Li < >>>>>>>>>> ethanopensou...@gmail.com>: >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Stig, >>>>>>>>>>>> >>>>>>>>>>>> Do you know what’s the versioning standard we have been >> following >>>>>> (to >>>>>>>>>>>> determine a 2.0.1 release or 2.1.0 release) ? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> On Jul 26, 2019, at 12:26 PM, Stig Rohde Døssing < >>>>>>>>>> stigdoess...@gmail.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Sounds great, thanks Ethan. >>>>>>>>>>>>> >>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li < >>>>>>>>>>>> ethanopensou...@gmail.com>: >>>>>>>>>>>>> >>>>>>>>>>>>>> It’s good idea to do more frequent release. I can run the >> next >>>>>>>>>> release. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I will take a look at both PRs. Other than that, I think we >> should >>>>>>>>>> also >>>>>>>>>>>>>> get https://github.com/apache/storm/pull/3093 < >>>>>>>>>>>>>> https://github.com/apache/storm/pull/3093> in the new >> release. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> On Jul 26, 2019, at 11:58 AM, Stig Rohde Døssing < >>>>>>>>>>>> stigdoess...@gmail.com> >>>>>>>>>>>>>> wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I think we've talked about more frequent releases before. >>>>>> Releasing >>>>>>>>>> new >>>>>>>>>>>>>>> versions every few months means people don't have to wait >> long >>>>>> for >>>>>>>>>>>> fixes >>>>>>>>>>>>>> to >>>>>>>>>>>>>>> get out, and smaller releases are probably also easier for >> users >>>>>> to >>>>>>>>>> get >>>>>>>>>>>>>> to >>>>>>>>>>>>>>> grips with (the fix list for 2.0.0 is enormous). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> With that in mind, I think we should start looking at the >> next >>>>>> 2.x >>>>>>>>>>>>>> release >>>>>>>>>>>>>>> (2.0.1 or 2.1.0?), since it's been a couple of months since >> 2.0.0 >>>>>>>>>>>>>> released. >>>>>>>>>>>>>>> The fix list would be >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>> >> https://issues.apache.org/jira/issues/?jql=project%20%3D%20STORM%20AND%20fixVersion%20%3D%202.0.1 >>>>>>>>>>>>>>> . >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Govind and Ethan have offered to run the next release, and >> help >>>>>>>>>>>> validate >>>>>>>>>>>>>>> our release process guidelines. Would one of you have time >> to >>>>>> work >>>>>>>>>> on a >>>>>>>>>>>>>>> release in the near future? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It would be good to take a look at currently open PRs and >> decide >>>>>>>>>> which >>>>>>>>>>>> we >>>>>>>>>>>>>>> feel need to get merged before the next release. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I would like to see at least >>>>>>>>>> https://github.com/apache/storm/pull/2990 >>>>>>>>>>>>>>> merged >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> https://github.com/apache/storm/pull/2878 seems like it's >> close >>>>>> to >>>>>>>>>> be >>>>>>>>>>>>>>> mergeable too? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >>>>>> >>>> >>> >>
