Sounds good Ethan. Derek, I also think being clear about how long we expect to support a release line is a good idea. Maybe we should do a separate discuss thread on this, or if you already have a good idea for what the policy should look like you could put it up as a PR for either the Downloads page or a new page on the Storm site?
Den søn. 11. aug. 2019 kl. 08.37 skrev Ethan Li <[email protected]>: > I am doing the release following > https://github.com/apache/storm/blob/master/RELEASING.md < > https://github.com/apache/storm/blob/master/RELEASING.md> . I made some > progress but I have some questions so I just sent an email to Taylor. > > Please don’t merge anything to master or 2.1.x-branch for now. Thanks > > Best, > Ethan > > > > On Aug 9, 2019, at 4:45 PM, Ethan Li <[email protected]> wrote: > > > > Currently we have two outstanding PRs that we wanted to include in the > new release: > > > > https://github.com/apache/storm/pull/3096 < > https://github.com/apache/storm/pull/3096> (Travis has some issues > connecting to repository.apache.org <http://repository.apache.org/> > recently. Travis build fails consistently) > > https://github.com/apache/storm/pull/2878 < > https://github.com/apache/storm/pull/2878> (Some comments are to be > addressed but Author hasn’t responded yet.) > > > > It’s not absolutely necessary to include them in this new release so I > think I should move forward with the release process. These two and other > PRs can be included in the next release. > > > > For the release, I will create a new branch 2.1.x-branch based on > current master branch, and release 2.1.0 from there. I will then move > master to 2.2.0-SNAPSHOT. Please let me know if there is any objections. > > > > Thanks, > > Ethan > > > > > >> On Aug 9, 2019, at 2:53 PM, Derek Dagit <[email protected] <mailto: > [email protected]>> wrote: > >> > >>> We might not able to say how long we want to support a specific > >>> release line but I would love to see a clear release policy being > >>> made. > >> > >> That makes sense. It seems better for us not to choose a specific > >> calendar date or duration of time. > >> > >> - We do not want too many release lines supported concurrently. > >> - We want devs and users to know what to expect. > >> > >> -- > >> Derek > >> > >> On Fri, Aug 09, 2019 at 10:32:59AM -0500, Ethan Li wrote: > >>> > >>> Derek, > >>> > >>> I think it’s a good idea to be more clear on the versioning and > release process so users and developers know what to expect. We might not > able to say how long we want to support a specific release line but I would > love to see a clear release policy being made. > >>> > >>> Thanks, > >>> Ethan > >>> > >>>> On Aug 9, 2019, at 8:53 AM, Derek Dagit <[email protected] <mailto: > [email protected]>> wrote: > >>>> > >>>> On Fri, Aug 09, 2019 at 02:35:57PM +0200, Stig Rohde Døssing wrote: > >>>>> 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. Derek, > >>>> > >>>> This is a better link: > https://cwiki.apache.org/confluence/display/TS/Release+Management < > https://cwiki.apache.org/confluence/display/TS/Release+Management> > >>>> > >>>> This example, where "RM" means "Release Manager": > >>>> > >>>>> 1. We promise to make 1 major release / year, but the RM and > community > >>>>> can of course make more as necessary > >>>>> > >>>>> 2. We only make releases off the LTS branches, which are cut once a > >>>>> year off master > >>>>> > >>>>> 3. Master is always open, for any type of change (including > >>>>> incompatible changes). But don't break compatibility just for fun! > >>>>> > >>>>> 4. Master is always stable, i.e. commits should be properly tested > and > >>>>> reviewed before committed to master. > >>>>> > >>>>> 5. All releases are stable releases, following strict Semantic > >>>>> Versioning. > >>>>> > >>>>> 6. Minor releases are made at the discretion at the discretion of the > >>>>> community and the RM. > >>>>> > >>>>> 7. Minor releases can include new (small / safe) features, but must > be > >>>>> compatible within the LTS major version. > >>>>> > >>>>> 8. The LTS cycle, 2 years + 6 months Sunset, does not reset when we > >>>>> make a minor release. > >>>> > >>>> > >>>> Now, I am not proposing we do exactly this. The goal would be to set > >>>> expectations among developers and the community, and here is one > >>>> concrete example of how it could be done. > >>>> > >>>>> 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 > >>>> > >>>> Yeah, that sounds reasonable to me. If we choose to commit to > something > >>>> like the above, we should base the decision in part on what kind of > >>>> resources we have so that we do not over-commit. > >>>> > >>>> > >>>> > >>>>> Den fre. 9. aug. 2019 kl. 00.15 skrev Derek Dagit <[email protected] > <mailto:[email protected]>>: > >>>>> > >>>>>> 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/ <https://semver.org/>). > >>>>>> > >>>>>> Apache Traffic Server does something like this, to name one project: > >>>>>> > >>>>>> https://trafficserver.apache.org/downloads < > 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 <[email protected]> > >>>>>> wrote: > >>>>>>>> > >>>>>>>> Yes thanks. > >>>>>>>> > >>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing < > >>>>>> [email protected]> 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 < > >>>>>> [email protected]>: > >>>>>>>>> > >>>>>>>>>> I got my pgp key signed by Bryan W. Call <[email protected] > <mailto: > >>>>>>>>>> [email protected]>> (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 < > >>>>>> [email protected]> > >>>>>>>>>> wrote: > >>>>>>>>>>> > >>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense. > >>>>>>>>>>> > >>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan Li < > >>>>>>>>>> [email protected]>: > >>>>>>>>>>> > >>>>>>>>>>>> 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 <[email protected] > > > >>>>>> 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 < > >>>>>> [email protected]> > >>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> Thanks Stig. I will look into it. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM, Stig Rohde Døssing < > >>>>>>>>>>>> [email protected]> > >>>>>>>>>>>>>> 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 < > >>>>>>>>>>>>>> [email protected]>: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> 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 < > >>>>>>>>>>>>>> [email protected]> > >>>>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Sounds great, thanks Ethan. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019 kl. 19.16 skrev Ethan Li < > >>>>>>>>>>>>>>>> [email protected]>: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> 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 < > >>>>>>>>>>>>>>>> [email protected]> > >>>>>>>>>>>>>>>>>> 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? > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>> > >>>>>>> > >>>>>> > >>> > > > >
