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 <da...@apache.org> 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 <da...@apache.org> 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 >>> >>> 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 <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? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>> >>>>> >>
