storm-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ethan Li <ethanopensou...@gmail.com>
Subject Re: [DISCUSS] Next 2.x release
Date Sun, 11 Aug 2019 06:37:25 GMT
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 <ethanopensource@gmail.com> 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 <dagit@apache.org <mailto:dagit@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 <dagit@apache.org <mailto:dagit@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
<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 <dagit@apache.org
<mailto:dagit@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/ <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 <ethanopensource@gmail.com>
>>>>>> wrote:
>>>>>>>> 
>>>>>>>> Yes thanks.
>>>>>>>> 
>>>>>>>>> On Aug 7, 2019, at 10:39 AM, Stig Rohde Døssing <
>>>>>> stigdoessing@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 <
>>>>>> ethanopensource@gmail.com>:
>>>>>>>>> 
>>>>>>>>>> I got my pgp key signed by Bryan W. Call <bcall@apache.org
<mailto:
>>>>>>>>>> bcall@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
<
>>>>>> stigdoessing@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Thanks Ethan, yes 2.1.0 makes sense.
>>>>>>>>>>> 
>>>>>>>>>>> Den man. 29. jul. 2019 kl. 23.43 skrev Ethan
Li <
>>>>>>>>>> ethanopensource@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
<hmclouro@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 <
>>>>>> ethanopensource@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Thanks Stig. I will look into it.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Jul 26, 2019, at 3:06 PM,
Stig Rohde Døssing <
>>>>>>>>>>>> stigdoessing@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 <
>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>> stigdoessing@gmail.com>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Sounds great, thanks
Ethan.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Den fre. 26. jul. 2019
kl. 19.16 skrev Ethan Li <
>>>>>>>>>>>>>>>> ethanopensource@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 <
>>>>>>>>>>>>>>>> stigdoessing@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?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>> 
> 


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message