> 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]> 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 <[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/). > >>> > >>> 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 <[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? > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>> > >>>>>>> > >>>>> > >>>> > >>> >
