Just in case if anyone happens to know the answer: I created a branch https://github.com/apache/storm/tree/2.1.x-branch <https://github.com/apache/storm/tree/2.1.x-branch> and ran “mvn:prepare” and “mvn:perform”. It created two commits and created a v2.1.0 git tag. But I realized that the pom version under storm-dist was not updated and it’s still 2.0.1-SNAPSHOT. I checked the commits in other tags like https://github.com/apache/storm/commits/v2.0.0 <https://github.com/apache/storm/commits/v2.0.0> and it looks like storm-dist got updated within the “mvn:prepare” step. How do I get storm-dist pom version updated with “mv:prepare”?
I am currently blocked on this. Any help will be appreciated. Thanks, Ethan > On Aug 12, 2019, at 2:38 AM, Stig Rohde Døssing <[email protected]> > wrote: > > 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? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>> >>> >> >>
