Re: [DISCUSS] consider EOL for version lines

[Jungtaek Lim]

Did download page being reverted only from published site? I can see
release notes are published (so I guess gitpubsub works well) but download
page doesn't represent current storm-site. Is it due to LGPL issue on Storm
1.2.0?

2018년 2월 17일 (토) 오전 2:18, P. Taylor Goetz 님이 작성:

> As part of the release process I updated the download page [1] to move
> older releases to archive.a.o as requested by INFRA. I also removed the
> “Current Release” sections for 0.9.x and 0.10.x to make it more clear that
> those lines are no longer supported.
>
> If we want to add a more explicit statement to the download page, we can
> certainly do that as well.
>
> -Taylor
>
> [1] http://storm.apache.org/downloads.html
>
> > On Feb 13, 2018, at 4:45 PM, Jungtaek Lim  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  >님이
> > 작성:
> >
> >> 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  >:
> >>>
>  +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 :
> >> +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"  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.
> >>>
> 

Re: [DISCUSS] consider EOL for version lines

[P. Taylor Goetz]

As part of the release process I updated the download page [1] to move older 
releases to archive.a.o as requested by INFRA. I also removed the “Current 
Release” sections for 0.9.x and 0.10.x to make it more clear that those lines 
are no longer supported.

If we want to add a more explicit statement to the download page, we can 
certainly do that as well.

-Taylor

[1] http://storm.apache.org/downloads.html

> On Feb 13, 2018, at 4:45 PM, Jungtaek Lim  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 님이
> 작성:
> 
>> 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 :
>>> 
 +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 :
>> +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"  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

Re: [DISCUSS] consider EOL for version lines

[P. Taylor Goetz]

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  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 님이
> 작성:
> 
>> 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 :
>>> 
 +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 :
>> +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"  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

Re: [DISCUSS] consider EOL for version lines

[Jungtaek Lim]

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 님이
작성:

> 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 :
> >
> > > +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 :
> > > >> +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"  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)
> > > >>
> > > >>
> > > >>
> > > >
> > >
> > >
> >
>

Re: [DISCUSS] consider EOL for version lines

[Erik Weathers]

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  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 :
>
> > +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 :
> > >> +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"  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)
> > >>
> > >>
> > >>
> > >
> >
> >
>

Re: [DISCUSS] consider EOL for version lines

[Stig Rohde Døssing]

+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 :

> +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 :
> >> +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"  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)
> >>
> >>
> >>
> >
>
>

Re: [DISCUSS] consider EOL for version lines

[Hugo Da Cruz Louro]

+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 
>  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 :
>> +1 to maintaining 3 version lines as suggested by Jungtaek.
>> 
>> On 2/13/18, 9:51 AM, "Arun Iyer on behalf of Arun Mahadevan" 
>>  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"  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)
>> 
>> 
>> 
> 

Re: [DISCUSS] consider EOL for version lines

[Alexandre Vermeerbergen]

+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 :
> +1 to maintaining 3 version lines as suggested by Jungtaek.
>
> On 2/13/18, 9:51 AM, "Arun Iyer on behalf of Arun Mahadevan" 
>  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"  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)
>
>
>

Re: [DISCUSS] consider EOL for version lines

[Priyank Shah]

+1 to maintaining 3 version lines as suggested by Jungtaek.

On 2/13/18, 9:51 AM, "Arun Iyer on behalf of Arun Mahadevan" 
 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"  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)

Re: [DISCUSS] consider EOL for version lines

[Arun Mahadevan]

+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"  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)

[DISCUSS] consider EOL for version lines

[Jungtaek Lim]

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)