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? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>> >
