This (3 version lines) is effectively what we’ve been doing — when a new 
version comes out major/minor version comes out, we stop updating/supporting 
the oldest previous version. For example, if we release 2.0 or 1.3 
(hypothetical), we would EOL 1.0.x. In some cases, like a security 
vulnerability, we may revisit an older release, but that’s fairly rare.

I agree that making it more explicit would help users. There’s not much to do 
other than update the downloads page and clean up dist.a.o.

-Taylor

> On Feb 13, 2018, at 4:45 PM, Jungtaek Lim <kabh...@gmail.com> wrote:
> 
> We're in discussion to split out storm-kafka-client to have separate
> release version and cycle. Since we have applied necessary changes to
> storm-core of 1.1.x/1.0.x, unless storm-kafka-client needs more changes on
> storm-core, storm-core 1.1.x/1.0.x should be compatible with
> storm-kafka-client be compatible with storm-core 1.x.
> 
> I'm OK to keep the 1.0.x version lines specifically for storm-mesos (and
> then we would end up keeping 1.1.x version line too) if we can't avoid the
> case, but I couldn't guarantee all the bug fixes should be ported back to
> 1.0.x. We even often don't port back the bug fixes to 1.0.x version lines
> when 1.1 is the active minor version of Storm unless the fixes are
> critical. That means we may not port back the bug fixes to 1.1.x after
> announcing 1.2.0 and 1.2.x-branch is cut. As we all know, it greatly
> reduces the maintenance cost. It does make sense for storm-kafka-client to
> do the backport for 1.1.x/1.0.x branches because huge changes are just
> applied (though I guess the experiment described above may resolve such
> issue), but not for others including storm-core except critical/blocker
> issues.
> 
> So in storm-mesos view, it would be better to catch up with highest
> possible version (that's why I hope to adopt storm-mesos in storm repo,
> maybe not likely to happen for now), and I understand storm-mesos can't for
> now because of Storm's issue. I wish the investigation of "Storm on X"
> would occur actively sooner than later, so that it can be included as
> earlier version of Storm 2.x (ideally 2.0.0 but it is just an ideal view).
> 
> Anyway, looks like there is no objection to announce 0.10.x/0.9.x
> explicitly EOL.
> 
> - Jungtaek Lim (HeartSaVioR)
> 
> 2018년 2월 14일 (수) 오전 6:02, Erik Weathers <eweath...@groupon.com.invalid>님이
> 작성:
> 
>> Thanks for keeping storm-mesos in mind Stig. :)  I'd be most worried about
>> any issues we might see with the backported storm-kafka-client and how we
>> *might* need to fix bugs in 1.0.x.  At least it should be easy to
>> cherry-pick fixes back into 1.0.x after the backport-stomping of
>> STORM-2937.
>> 
>> Look forward to working with Bobby to get a long term plan for storm to run
>> on mesos in 2.x+.
>> 
>> - Erik
>> 
>> On Tue, Feb 13, 2018 at 11:26 AM, Stig Rohde Døssing <
>> stigdoess...@gmail.com
>>> wrote:
>> 
>>> +1 to maintain 3 version lines, though we may want to look at what we can
>>> do for storm mesos, which I think it currently stuck on 1.0.x.
>>> 
>>> 2018-02-13 20:17 GMT+01:00 Hugo Da Cruz Louro <hlo...@hortonworks.com>:
>>> 
>>>> +1 to maintain 3 version lines. Let’s properly announce that in our
>>> portal
>>>> and users list such that users know what’s coming.
>>>> 
>>>> Agree with focusing on 2.0 which has a lot of improvements, rather than
>>>> 1.x, x >= 3.
>>>> 
>>>>> On Feb 13, 2018, at 10:43 AM, Alexandre Vermeerbergen <
>>>> avermeerber...@gmail.com> wrote:
>>>>> 
>>>>> +1 (non binding) to maintaining less version lines, provided that
>>>>> 1.2.x branch is maintained long enough to allow progressive adoption
>>>>> of 2.x
>>>>> 
>>>>> Alexandre Vermeerbergen
>>>>> 
>>>>> 2018-02-13 19:38 GMT+01:00 Priyank Shah <ps...@hortonworks.com>:
>>>>>> +1 to maintaining 3 version lines as suggested by Jungtaek.
>>>>>> 
>>>>>> On 2/13/18, 9:51 AM, "Arun Iyer on behalf of Arun Mahadevan" <
>>>> ai...@hortonworks.com on behalf of ar...@apache.org> wrote:
>>>>>> 
>>>>>>   +1 to maintain 3 version lines.
>>>>>> 
>>>>>>   I think the next focus should be 2.0.0 than 1.3.0.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>>   On 2/12/18, 11:40 PM, "Jungtaek Lim" <kabh...@gmail.com> wrote:
>>>>>>> 
>>>>>>> Hi devs,
>>>>>>> 
>>>>>>> I've noticed that we are providing 4 different version lines
>> (1.1.x,
>>>> 1.0.x,
>>>>>>> 0.10.x, 0.9.x) in download page, and I expect we will add one more
>>> for
>>>>>>> 1.2.0. Moreover, we have one more develop version line (2.0.0 -
>>> master)
>>>>>>> which most of development happens there.
>>>>>>> 
>>>>>>> Recently we're releasing 3 version lines (1.0.6 / 1.1.2 / 1.2.0)
>>>>>>> simultaneously and it took heavy effort to track all the RCs and
>>>> verify all
>>>>>>> of them. I guess release manager would take more overhead of
>>>> releasing, and
>>>>>>> it doesn't make sense for me if we continue maintaining all of
>> them.
>>>>>>> 
>>>>>>> Ideally I'd like to propose maintaining three version lines: 2.0.0
>>>> (next
>>>>>>> major) / 1.3.0 (next minor - may not happen) / 1.2.1 (next bugfix)
>>> and
>>>>>>> making others EOL (that respects semantic versioning and even other
>>>>>>> projects tend to maintain only two version lines), but if someone
>>>> feels too
>>>>>>> aggressive, I propose at least we explicitly announce EOL to 0.x
>>>> version
>>>>>>> lines and get rid of any supports (downloads) for them.
>>>>>>> 
>>>>>>> Would like to hear your opinion.
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> Jungtaek Lim (HeartSaVioR)
>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>> 
>> 

Reply via email to