You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@accumulo.apache.org by Christopher <ct...@apache.org> on 2019/10/31 01:00:38 UTC
[LAZY][VOTE] A basic, but concrete, LTS proposal
Following up from the discussion at
https://lists.apache.org/thread.html/560bfe8d911be5b829e6250a34dfa1ace0584b24251651be1c77d724@%3Cdev.accumulo.apache.org%3E
I think we should adopt this LTS concept:
LTS releases:
* Designate a new LTS line every 2 years (designation communicates
intent to support/patch)
* Target patch releases to LTS lines for 3 years
* EOL previous LTS line when the new one has been available for 1 year
non-LTS releases:
* Periodic releases that aren't expected to be supported with patch releases
* Can still create patch releases, but only until the next LTS/non-LTS
release line (typically only for critical bugs.... because we won't
keep a maintenance branch around for non-LTS... instead, we'll roll
bugfixes into the next release, or branch off the tag for a critical
bug)
* non-LTS releases are EOL as soon as the next LTS/non-LTS release
line is created
Transition plan:
* Define LTS on the downloads page of the website
* Designate 1.9 as first (and currently only) LTS release line
* Mark the LTS expected EOL date on the downloads page next to the LTS
releases (to the month... we don't need to get too granular/pedantic)
What this proposal does *not* do is determine how frequently we
release. It *only* determines which versions we will designate as LTS.
So, this doesn't bind us to any fixed release schedule, and we can
release as frequently (or infrequently) as our community wishes
(though I hope the non-LTS releases will occur more frequently, as
they can take more creative risks). But, the main point of this
proposal is that every two years, we'll designate a new release that
will take over as our main "supported line" that will be low-risk, and
more stable over time. The 1-year overlap for people to upgrade from
one LTS to the next in this plan is pretty useful, too, I think.
Here's an example set of hypothetical releases (except 1.9.x and
2.0.0, which are real) under this plan:
* LTS (2018): 1.9.0 -> 1.9.1 -> 1.9.2 -> ... -> EOL(2021)
* non-LTS (2018-2020): 2.0.0 -> 2.1.0 -> 2.1.1 (critical bug fix) -> 2.2.0
* LTS (2020): 2.3.0 -> 2.3.1 -> 2.3.2 -> ... -> EOL(2023)
* non-LTS (2020-2022): 2.4.0 -> 2.5.0 -> 3.0.0
* LTS (2022): 3.1.0 -> 3.1.1 -> 3.1.2 -> ... -> EOL(2025)
This LTS proposal isn't perfect and doesn't solve all possible issues,
but I think it establishes the groundwork for future release
plans/schedules and helps frame discussions about future releases,
that we can work through later if needed.
If there's general consensus on the basic proposal here, I can start
updating the website after 72 hours (lazy consensus) to add the LTS
definition and mark things on the downloads page, accordingly. If it
turns into a significant discussion, I'll hold off on anything until
the discussion points are resolved. If there's disagreement that can't
be resolved, I'll start a more formal vote later (or give up due to
lost motivation, worst case :smile:).
--
Christopher
Re: [LAZY][VOTE] A basic, but concrete, LTS proposal
Posted by Christopher <ct...@apache.org>.
Since the 1.10 vote wrapped up in the other thread, it appears that
we'll be releasing 1.10.0 instead of 1.9.4. Since there's general
consensus in this thread about the proposed strategy, I'll start
helping get the 1.10 release out with the changes we voted on, and
then implementing the strategy discussed here, with 1.10 as the first
LTS release (and dropping the 2.0 branch as it's not an LTS release).
Thanks for the discussion, everybody. Let's keep the conversation
going, as needed, to quickly resolve any issues that arise as we
proceed.
On Mon, Nov 4, 2019 at 12:00 PM Christopher <ct...@apache.org> wrote:
>
> It seems like there's general consensus here (and no objections), for
> adopting this LTS strategy. There were some good questions raised,
> though, whose answers can be added to the website to communicate
> things. However, since the idea of releasing 1.10 came up, I'll wait
> for that discussion/vote/activity to settle before making any changes
> to the website regarding LTS.
>
> On Mon, Nov 4, 2019 at 11:52 AM Christopher <ct...@apache.org> wrote:
> >
> > On Mon, Nov 4, 2019 at 10:55 AM Keith Turner <ke...@deenlo.com> wrote:
> > >
> > > On Fri, Nov 1, 2019 at 7:43 PM Nikhil Manchanda <sl...@gmail.com> wrote:
> > > >
> > > >
> > > > +1
> > > > (non-binding)
> > > >
> > > > I'm in favor of the LTS proposal as it stands. It provides a clear
> > > > way for our development and release teams to signal to users the
> > > > expected life of an Accumulo release. It also puts in place a
> > > > basic framework in terms of what we consider reasonable windows
> > > > for patching and support. It also gives developers an avenue to
> > > > run some of the more creative experiments on non LTS lines without
> > > > affecting stability of LTS releases.
> > > >
> > > > Totally agree that this is likely going to be an evolving effort
> > > > as we find what works well here. That said, this is a great
> > > > starting point.
> > > >
> > > > One question that I did have (especially being new in the area) is
> > > > whether we have any dependencies that themselves offer support for
> > > > shorter periods of time than our (3-year) LTS window. If so, does
> > > > that mean that we might be on the hook for any issues discovered
> > > > with such dependencies?
> > >
> > > I have always viewed Accumulo as not being very prescriptive about
> > > what dependencies are used at runtime. For the situation you mention,
> > > if Accumulo source needs to change in order to allow a newer version
> > > of a dep to be used for security reasons we could make that change in
> > > a patch version. Ideally the Accumulo source change allows the new
> > > and old version of the dependency to be used. If this is not
> > > possible, personally I would still like to see the change made with a
> > > prominent mention in the release notes.
> > >
> >
> > I agree with Keith about not being very prescriptive about runtime
> > dependencies. We can (and should) try to pay attention to dependency
> > lifecycles in order to inform our development in Accumulo, but
> > ultimately, the runtime environment is a downstream concern
> > (vendors/distros/packagers/users).
> >
> > What we mean by "support" may be different from other uses of that
> > word, especially since we're comprised of volunteers. Here, I think
> > what we mean is simply a declaration of our intent to focus our
> > development activities around those release lines in the LTS window.
> > It's really more of an exercise in communicating intent and managing
> > expectations, than it is a guarantee of anything, and certainly not
> > guarantees for things developed by other communities that we merely
> > consume.
Re: [LAZY][VOTE] A basic, but concrete, LTS proposal
Posted by Christopher <ct...@apache.org>.
It seems like there's general consensus here (and no objections), for
adopting this LTS strategy. There were some good questions raised,
though, whose answers can be added to the website to communicate
things. However, since the idea of releasing 1.10 came up, I'll wait
for that discussion/vote/activity to settle before making any changes
to the website regarding LTS.
On Mon, Nov 4, 2019 at 11:52 AM Christopher <ct...@apache.org> wrote:
>
> On Mon, Nov 4, 2019 at 10:55 AM Keith Turner <ke...@deenlo.com> wrote:
> >
> > On Fri, Nov 1, 2019 at 7:43 PM Nikhil Manchanda <sl...@gmail.com> wrote:
> > >
> > >
> > > +1
> > > (non-binding)
> > >
> > > I'm in favor of the LTS proposal as it stands. It provides a clear
> > > way for our development and release teams to signal to users the
> > > expected life of an Accumulo release. It also puts in place a
> > > basic framework in terms of what we consider reasonable windows
> > > for patching and support. It also gives developers an avenue to
> > > run some of the more creative experiments on non LTS lines without
> > > affecting stability of LTS releases.
> > >
> > > Totally agree that this is likely going to be an evolving effort
> > > as we find what works well here. That said, this is a great
> > > starting point.
> > >
> > > One question that I did have (especially being new in the area) is
> > > whether we have any dependencies that themselves offer support for
> > > shorter periods of time than our (3-year) LTS window. If so, does
> > > that mean that we might be on the hook for any issues discovered
> > > with such dependencies?
> >
> > I have always viewed Accumulo as not being very prescriptive about
> > what dependencies are used at runtime. For the situation you mention,
> > if Accumulo source needs to change in order to allow a newer version
> > of a dep to be used for security reasons we could make that change in
> > a patch version. Ideally the Accumulo source change allows the new
> > and old version of the dependency to be used. If this is not
> > possible, personally I would still like to see the change made with a
> > prominent mention in the release notes.
> >
>
> I agree with Keith about not being very prescriptive about runtime
> dependencies. We can (and should) try to pay attention to dependency
> lifecycles in order to inform our development in Accumulo, but
> ultimately, the runtime environment is a downstream concern
> (vendors/distros/packagers/users).
>
> What we mean by "support" may be different from other uses of that
> word, especially since we're comprised of volunteers. Here, I think
> what we mean is simply a declaration of our intent to focus our
> development activities around those release lines in the LTS window.
> It's really more of an exercise in communicating intent and managing
> expectations, than it is a guarantee of anything, and certainly not
> guarantees for things developed by other communities that we merely
> consume.
Re: [LAZY][VOTE] A basic, but concrete, LTS proposal
Posted by Christopher <ct...@apache.org>.
On Mon, Nov 4, 2019 at 10:55 AM Keith Turner <ke...@deenlo.com> wrote:
>
> On Fri, Nov 1, 2019 at 7:43 PM Nikhil Manchanda <sl...@gmail.com> wrote:
> >
> >
> > +1
> > (non-binding)
> >
> > I'm in favor of the LTS proposal as it stands. It provides a clear
> > way for our development and release teams to signal to users the
> > expected life of an Accumulo release. It also puts in place a
> > basic framework in terms of what we consider reasonable windows
> > for patching and support. It also gives developers an avenue to
> > run some of the more creative experiments on non LTS lines without
> > affecting stability of LTS releases.
> >
> > Totally agree that this is likely going to be an evolving effort
> > as we find what works well here. That said, this is a great
> > starting point.
> >
> > One question that I did have (especially being new in the area) is
> > whether we have any dependencies that themselves offer support for
> > shorter periods of time than our (3-year) LTS window. If so, does
> > that mean that we might be on the hook for any issues discovered
> > with such dependencies?
>
> I have always viewed Accumulo as not being very prescriptive about
> what dependencies are used at runtime. For the situation you mention,
> if Accumulo source needs to change in order to allow a newer version
> of a dep to be used for security reasons we could make that change in
> a patch version. Ideally the Accumulo source change allows the new
> and old version of the dependency to be used. If this is not
> possible, personally I would still like to see the change made with a
> prominent mention in the release notes.
>
I agree with Keith about not being very prescriptive about runtime
dependencies. We can (and should) try to pay attention to dependency
lifecycles in order to inform our development in Accumulo, but
ultimately, the runtime environment is a downstream concern
(vendors/distros/packagers/users).
What we mean by "support" may be different from other uses of that
word, especially since we're comprised of volunteers. Here, I think
what we mean is simply a declaration of our intent to focus our
development activities around those release lines in the LTS window.
It's really more of an exercise in communicating intent and managing
expectations, than it is a guarantee of anything, and certainly not
guarantees for things developed by other communities that we merely
consume.
Re: [LAZY][VOTE] A basic, but concrete, LTS proposal
Posted by Mike Miller <mm...@apache.org>.
+1
On Mon, Nov 4, 2019 at 10:55 AM Keith Turner <ke...@deenlo.com> wrote:
> On Fri, Nov 1, 2019 at 7:43 PM Nikhil Manchanda <sl...@gmail.com>
> wrote:
> >
> >
> > +1
> > (non-binding)
> >
> > I'm in favor of the LTS proposal as it stands. It provides a clear
> > way for our development and release teams to signal to users the
> > expected life of an Accumulo release. It also puts in place a
> > basic framework in terms of what we consider reasonable windows
> > for patching and support. It also gives developers an avenue to
> > run some of the more creative experiments on non LTS lines without
> > affecting stability of LTS releases.
> >
> > Totally agree that this is likely going to be an evolving effort
> > as we find what works well here. That said, this is a great
> > starting point.
> >
> > One question that I did have (especially being new in the area) is
> > whether we have any dependencies that themselves offer support for
> > shorter periods of time than our (3-year) LTS window. If so, does
> > that mean that we might be on the hook for any issues discovered
> > with such dependencies?
>
> I have always viewed Accumulo as not being very prescriptive about
> what dependencies are used at runtime. For the situation you mention,
> if Accumulo source needs to change in order to allow a newer version
> of a dep to be used for security reasons we could make that change in
> a patch version. Ideally the Accumulo source change allows the new
> and old version of the dependency to be used. If this is not
> possible, personally I would still like to see the change made with a
> prominent mention in the release notes.
>
>
> >
> > Thanks,
> > Nikhil
> >
> >
> > On Thu, Oct 31 2019, Keith Turner <ke...@deenlo.com> wrote:
> > > +1
> > >
> > > I am in favor of the LTS idea because I think it makes it more
> > > efficient for everyone to easily come together and focus their
> > > efforts
> > > in the same direction for the benefit of everyone.
> > >
> > > I think this is a really good starting plan for LTS. Overtime
> > > we will
> > > probably find issues with the plan and we can modify the plan as
> > > we
> > > go. I can help write up the documentation for the initial plan.
> > > One
> > > thing I would like to achieve in the writeup is communicating
> > > that
> > > things are not set in stone. Thinking through this I thought
> > > about
> > > possibly including the following points in the writeup.
> > >
> > > * Any plans for the next LTS are subject to change.
> > > * Patches for the current LTS will be accepted until at least
> > > the
> > > currently agreed date.
> > > * Changes to the LTS process can be brought up on the dev
> > > list.
> > >
> > >
> > > On Wed, Oct 30, 2019 at 9:00 PM Christopher
> > > <ct...@apache.org> wrote:
> > >>
> > >> Following up from the discussion at
> > >>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2F560bfe8d911be5b829e6250a34dfa1ace0584b24251651be1c77d724%40%253Cdev.accumulo.apache.org%253E&data=02%7C01%7C%7Cccae8357ee444dac038f08d75e029b6e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637081237595720486&sdata=OFd9ssV3kP4jwOxcjOKkMPUil%2B%2B0bzhPbfbmPCU1i7Q%3D&reserved=0
> > >>
> > >> I think we should adopt this LTS concept:
> > >>
> > >> LTS releases:
> > >> * Designate a new LTS line every 2 years (designation
> > >> communicates
> > >> intent to support/patch)
> > >> * Target patch releases to LTS lines for 3 years
> > >> * EOL previous LTS line when the new one has been available for
> > >> 1 year
> > >>
> > >> non-LTS releases:
> > >> * Periodic releases that aren't expected to be supported with
> > >> patch releases
> > >> * Can still create patch releases, but only until the next
> > >> LTS/non-LTS
> > >> release line (typically only for critical bugs.... because we
> > >> won't
> > >> keep a maintenance branch around for non-LTS... instead, we'll
> > >> roll
> > >> bugfixes into the next release, or branch off the tag for a
> > >> critical
> > >> bug)
> > >> * non-LTS releases are EOL as soon as the next LTS/non-LTS
> > >> release
> > >> line is created
> > >>
> > >> Transition plan:
> > >>
> > >> * Define LTS on the downloads page of the website
> > >> * Designate 1.9 as first (and currently only) LTS release line
> > >> * Mark the LTS expected EOL date on the downloads page next to
> > >> the LTS
> > >> releases (to the month... we don't need to get too
> > >> granular/pedantic)
> > >>
> > >> What this proposal does *not* do is determine how frequently we
> > >> release. It *only* determines which versions we will designate
> > >> as LTS.
> > >> So, this doesn't bind us to any fixed release schedule, and we
> > >> can
> > >> release as frequently (or infrequently) as our community wishes
> > >> (though I hope the non-LTS releases will occur more frequently,
> > >> as
> > >> they can take more creative risks). But, the main point of this
> > >> proposal is that every two years, we'll designate a new release
> > >> that
> > >> will take over as our main "supported line" that will be
> > >> low-risk, and
> > >> more stable over time. The 1-year overlap for people to upgrade
> > >> from
> > >> one LTS to the next in this plan is pretty useful, too, I
> > >> think.
> > >>
> > >> Here's an example set of hypothetical releases (except 1.9.x
> > >> and
> > >> 2.0.0, which are real) under this plan:
> > >>
> > >> * LTS (2018): 1.9.0 -> 1.9.1 -> 1.9.2 -> ... -> EOL(2021)
> > >> * non-LTS (2018-2020): 2.0.0 -> 2.1.0 -> 2.1.1 (critical bug
> > >> fix) -> 2.2.0
> > >> * LTS (2020): 2.3.0 -> 2.3.1 -> 2.3.2 -> ... -> EOL(2023)
> > >> * non-LTS (2020-2022): 2.4.0 -> 2.5.0 -> 3.0.0
> > >> * LTS (2022): 3.1.0 -> 3.1.1 -> 3.1.2 -> ... -> EOL(2025)
> > >>
> > >> This LTS proposal isn't perfect and doesn't solve all possible
> > >> issues,
> > >> but I think it establishes the groundwork for future release
> > >> plans/schedules and helps frame discussions about future
> > >> releases,
> > >> that we can work through later if needed.
> > >>
> > >> If there's general consensus on the basic proposal here, I can
> > >> start
> > >> updating the website after 72 hours (lazy consensus) to add the
> > >> LTS
> > >> definition and mark things on the downloads page,
> > >> accordingly. If it
> > >> turns into a significant discussion, I'll hold off on anything
> > >> until
> > >> the discussion points are resolved. If there's disagreement
> > >> that can't
> > >> be resolved, I'll start a more formal vote later (or give up
> > >> due to
> > >> lost motivation, worst case :smile:).
> > >>
> > >> --
> > >> Christopher
>
Re: [LAZY][VOTE] A basic, but concrete, LTS proposal
Posted by Keith Turner <ke...@deenlo.com>.
On Fri, Nov 1, 2019 at 7:43 PM Nikhil Manchanda <sl...@gmail.com> wrote:
>
>
> +1
> (non-binding)
>
> I'm in favor of the LTS proposal as it stands. It provides a clear
> way for our development and release teams to signal to users the
> expected life of an Accumulo release. It also puts in place a
> basic framework in terms of what we consider reasonable windows
> for patching and support. It also gives developers an avenue to
> run some of the more creative experiments on non LTS lines without
> affecting stability of LTS releases.
>
> Totally agree that this is likely going to be an evolving effort
> as we find what works well here. That said, this is a great
> starting point.
>
> One question that I did have (especially being new in the area) is
> whether we have any dependencies that themselves offer support for
> shorter periods of time than our (3-year) LTS window. If so, does
> that mean that we might be on the hook for any issues discovered
> with such dependencies?
I have always viewed Accumulo as not being very prescriptive about
what dependencies are used at runtime. For the situation you mention,
if Accumulo source needs to change in order to allow a newer version
of a dep to be used for security reasons we could make that change in
a patch version. Ideally the Accumulo source change allows the new
and old version of the dependency to be used. If this is not
possible, personally I would still like to see the change made with a
prominent mention in the release notes.
>
> Thanks,
> Nikhil
>
>
> On Thu, Oct 31 2019, Keith Turner <ke...@deenlo.com> wrote:
> > +1
> >
> > I am in favor of the LTS idea because I think it makes it more
> > efficient for everyone to easily come together and focus their
> > efforts
> > in the same direction for the benefit of everyone.
> >
> > I think this is a really good starting plan for LTS. Overtime
> > we will
> > probably find issues with the plan and we can modify the plan as
> > we
> > go. I can help write up the documentation for the initial plan.
> > One
> > thing I would like to achieve in the writeup is communicating
> > that
> > things are not set in stone. Thinking through this I thought
> > about
> > possibly including the following points in the writeup.
> >
> > * Any plans for the next LTS are subject to change.
> > * Patches for the current LTS will be accepted until at least
> > the
> > currently agreed date.
> > * Changes to the LTS process can be brought up on the dev
> > list.
> >
> >
> > On Wed, Oct 30, 2019 at 9:00 PM Christopher
> > <ct...@apache.org> wrote:
> >>
> >> Following up from the discussion at
> >> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2F560bfe8d911be5b829e6250a34dfa1ace0584b24251651be1c77d724%40%253Cdev.accumulo.apache.org%253E&data=02%7C01%7C%7Cccae8357ee444dac038f08d75e029b6e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637081237595720486&sdata=OFd9ssV3kP4jwOxcjOKkMPUil%2B%2B0bzhPbfbmPCU1i7Q%3D&reserved=0
> >>
> >> I think we should adopt this LTS concept:
> >>
> >> LTS releases:
> >> * Designate a new LTS line every 2 years (designation
> >> communicates
> >> intent to support/patch)
> >> * Target patch releases to LTS lines for 3 years
> >> * EOL previous LTS line when the new one has been available for
> >> 1 year
> >>
> >> non-LTS releases:
> >> * Periodic releases that aren't expected to be supported with
> >> patch releases
> >> * Can still create patch releases, but only until the next
> >> LTS/non-LTS
> >> release line (typically only for critical bugs.... because we
> >> won't
> >> keep a maintenance branch around for non-LTS... instead, we'll
> >> roll
> >> bugfixes into the next release, or branch off the tag for a
> >> critical
> >> bug)
> >> * non-LTS releases are EOL as soon as the next LTS/non-LTS
> >> release
> >> line is created
> >>
> >> Transition plan:
> >>
> >> * Define LTS on the downloads page of the website
> >> * Designate 1.9 as first (and currently only) LTS release line
> >> * Mark the LTS expected EOL date on the downloads page next to
> >> the LTS
> >> releases (to the month... we don't need to get too
> >> granular/pedantic)
> >>
> >> What this proposal does *not* do is determine how frequently we
> >> release. It *only* determines which versions we will designate
> >> as LTS.
> >> So, this doesn't bind us to any fixed release schedule, and we
> >> can
> >> release as frequently (or infrequently) as our community wishes
> >> (though I hope the non-LTS releases will occur more frequently,
> >> as
> >> they can take more creative risks). But, the main point of this
> >> proposal is that every two years, we'll designate a new release
> >> that
> >> will take over as our main "supported line" that will be
> >> low-risk, and
> >> more stable over time. The 1-year overlap for people to upgrade
> >> from
> >> one LTS to the next in this plan is pretty useful, too, I
> >> think.
> >>
> >> Here's an example set of hypothetical releases (except 1.9.x
> >> and
> >> 2.0.0, which are real) under this plan:
> >>
> >> * LTS (2018): 1.9.0 -> 1.9.1 -> 1.9.2 -> ... -> EOL(2021)
> >> * non-LTS (2018-2020): 2.0.0 -> 2.1.0 -> 2.1.1 (critical bug
> >> fix) -> 2.2.0
> >> * LTS (2020): 2.3.0 -> 2.3.1 -> 2.3.2 -> ... -> EOL(2023)
> >> * non-LTS (2020-2022): 2.4.0 -> 2.5.0 -> 3.0.0
> >> * LTS (2022): 3.1.0 -> 3.1.1 -> 3.1.2 -> ... -> EOL(2025)
> >>
> >> This LTS proposal isn't perfect and doesn't solve all possible
> >> issues,
> >> but I think it establishes the groundwork for future release
> >> plans/schedules and helps frame discussions about future
> >> releases,
> >> that we can work through later if needed.
> >>
> >> If there's general consensus on the basic proposal here, I can
> >> start
> >> updating the website after 72 hours (lazy consensus) to add the
> >> LTS
> >> definition and mark things on the downloads page,
> >> accordingly. If it
> >> turns into a significant discussion, I'll hold off on anything
> >> until
> >> the discussion points are resolved. If there's disagreement
> >> that can't
> >> be resolved, I'll start a more formal vote later (or give up
> >> due to
> >> lost motivation, worst case :smile:).
> >>
> >> --
> >> Christopher
Re: [LAZY][VOTE] A basic, but concrete, LTS proposal
Posted by Nikhil Manchanda <sl...@gmail.com>.
+1
(non-binding)
I'm in favor of the LTS proposal as it stands. It provides a clear
way for our development and release teams to signal to users the
expected life of an Accumulo release. It also puts in place a
basic framework in terms of what we consider reasonable windows
for patching and support. It also gives developers an avenue to
run some of the more creative experiments on non LTS lines without
affecting stability of LTS releases.
Totally agree that this is likely going to be an evolving effort
as we find what works well here. That said, this is a great
starting point.
One question that I did have (especially being new in the area) is
whether we have any dependencies that themselves offer support for
shorter periods of time than our (3-year) LTS window. If so, does
that mean that we might be on the hook for any issues discovered
with such dependencies?
Thanks,
Nikhil
On Thu, Oct 31 2019, Keith Turner <ke...@deenlo.com> wrote:
> +1
>
> I am in favor of the LTS idea because I think it makes it more
> efficient for everyone to easily come together and focus their
> efforts
> in the same direction for the benefit of everyone.
>
> I think this is a really good starting plan for LTS. Overtime
> we will
> probably find issues with the plan and we can modify the plan as
> we
> go. I can help write up the documentation for the initial plan.
> One
> thing I would like to achieve in the writeup is communicating
> that
> things are not set in stone. Thinking through this I thought
> about
> possibly including the following points in the writeup.
>
> * Any plans for the next LTS are subject to change.
> * Patches for the current LTS will be accepted until at least
> the
> currently agreed date.
> * Changes to the LTS process can be brought up on the dev
> list.
>
>
> On Wed, Oct 30, 2019 at 9:00 PM Christopher
> <ct...@apache.org> wrote:
>>
>> Following up from the discussion at
>> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.apache.org%2Fthread.html%2F560bfe8d911be5b829e6250a34dfa1ace0584b24251651be1c77d724%40%253Cdev.accumulo.apache.org%253E&data=02%7C01%7C%7Cccae8357ee444dac038f08d75e029b6e%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637081237595720486&sdata=OFd9ssV3kP4jwOxcjOKkMPUil%2B%2B0bzhPbfbmPCU1i7Q%3D&reserved=0
>>
>> I think we should adopt this LTS concept:
>>
>> LTS releases:
>> * Designate a new LTS line every 2 years (designation
>> communicates
>> intent to support/patch)
>> * Target patch releases to LTS lines for 3 years
>> * EOL previous LTS line when the new one has been available for
>> 1 year
>>
>> non-LTS releases:
>> * Periodic releases that aren't expected to be supported with
>> patch releases
>> * Can still create patch releases, but only until the next
>> LTS/non-LTS
>> release line (typically only for critical bugs.... because we
>> won't
>> keep a maintenance branch around for non-LTS... instead, we'll
>> roll
>> bugfixes into the next release, or branch off the tag for a
>> critical
>> bug)
>> * non-LTS releases are EOL as soon as the next LTS/non-LTS
>> release
>> line is created
>>
>> Transition plan:
>>
>> * Define LTS on the downloads page of the website
>> * Designate 1.9 as first (and currently only) LTS release line
>> * Mark the LTS expected EOL date on the downloads page next to
>> the LTS
>> releases (to the month... we don't need to get too
>> granular/pedantic)
>>
>> What this proposal does *not* do is determine how frequently we
>> release. It *only* determines which versions we will designate
>> as LTS.
>> So, this doesn't bind us to any fixed release schedule, and we
>> can
>> release as frequently (or infrequently) as our community wishes
>> (though I hope the non-LTS releases will occur more frequently,
>> as
>> they can take more creative risks). But, the main point of this
>> proposal is that every two years, we'll designate a new release
>> that
>> will take over as our main "supported line" that will be
>> low-risk, and
>> more stable over time. The 1-year overlap for people to upgrade
>> from
>> one LTS to the next in this plan is pretty useful, too, I
>> think.
>>
>> Here's an example set of hypothetical releases (except 1.9.x
>> and
>> 2.0.0, which are real) under this plan:
>>
>> * LTS (2018): 1.9.0 -> 1.9.1 -> 1.9.2 -> ... -> EOL(2021)
>> * non-LTS (2018-2020): 2.0.0 -> 2.1.0 -> 2.1.1 (critical bug
>> fix) -> 2.2.0
>> * LTS (2020): 2.3.0 -> 2.3.1 -> 2.3.2 -> ... -> EOL(2023)
>> * non-LTS (2020-2022): 2.4.0 -> 2.5.0 -> 3.0.0
>> * LTS (2022): 3.1.0 -> 3.1.1 -> 3.1.2 -> ... -> EOL(2025)
>>
>> This LTS proposal isn't perfect and doesn't solve all possible
>> issues,
>> but I think it establishes the groundwork for future release
>> plans/schedules and helps frame discussions about future
>> releases,
>> that we can work through later if needed.
>>
>> If there's general consensus on the basic proposal here, I can
>> start
>> updating the website after 72 hours (lazy consensus) to add the
>> LTS
>> definition and mark things on the downloads page,
>> accordingly. If it
>> turns into a significant discussion, I'll hold off on anything
>> until
>> the discussion points are resolved. If there's disagreement
>> that can't
>> be resolved, I'll start a more formal vote later (or give up
>> due to
>> lost motivation, worst case :smile:).
>>
>> --
>> Christopher
Re: [LAZY][VOTE] A basic, but concrete, LTS proposal
Posted by Keith Turner <ke...@deenlo.com>.
+1
I am in favor of the LTS idea because I think it makes it more
efficient for everyone to easily come together and focus their efforts
in the same direction for the benefit of everyone.
I think this is a really good starting plan for LTS. Overtime we will
probably find issues with the plan and we can modify the plan as we
go. I can help write up the documentation for the initial plan. One
thing I would like to achieve in the writeup is communicating that
things are not set in stone. Thinking through this I thought about
possibly including the following points in the writeup.
* Any plans for the next LTS are subject to change.
* Patches for the current LTS will be accepted until at least the
currently agreed date.
* Changes to the LTS process can be brought up on the dev list.
On Wed, Oct 30, 2019 at 9:00 PM Christopher <ct...@apache.org> wrote:
>
> Following up from the discussion at
> https://lists.apache.org/thread.html/560bfe8d911be5b829e6250a34dfa1ace0584b24251651be1c77d724@%3Cdev.accumulo.apache.org%3E
>
> I think we should adopt this LTS concept:
>
> LTS releases:
> * Designate a new LTS line every 2 years (designation communicates
> intent to support/patch)
> * Target patch releases to LTS lines for 3 years
> * EOL previous LTS line when the new one has been available for 1 year
>
> non-LTS releases:
> * Periodic releases that aren't expected to be supported with patch releases
> * Can still create patch releases, but only until the next LTS/non-LTS
> release line (typically only for critical bugs.... because we won't
> keep a maintenance branch around for non-LTS... instead, we'll roll
> bugfixes into the next release, or branch off the tag for a critical
> bug)
> * non-LTS releases are EOL as soon as the next LTS/non-LTS release
> line is created
>
> Transition plan:
>
> * Define LTS on the downloads page of the website
> * Designate 1.9 as first (and currently only) LTS release line
> * Mark the LTS expected EOL date on the downloads page next to the LTS
> releases (to the month... we don't need to get too granular/pedantic)
>
> What this proposal does *not* do is determine how frequently we
> release. It *only* determines which versions we will designate as LTS.
> So, this doesn't bind us to any fixed release schedule, and we can
> release as frequently (or infrequently) as our community wishes
> (though I hope the non-LTS releases will occur more frequently, as
> they can take more creative risks). But, the main point of this
> proposal is that every two years, we'll designate a new release that
> will take over as our main "supported line" that will be low-risk, and
> more stable over time. The 1-year overlap for people to upgrade from
> one LTS to the next in this plan is pretty useful, too, I think.
>
> Here's an example set of hypothetical releases (except 1.9.x and
> 2.0.0, which are real) under this plan:
>
> * LTS (2018): 1.9.0 -> 1.9.1 -> 1.9.2 -> ... -> EOL(2021)
> * non-LTS (2018-2020): 2.0.0 -> 2.1.0 -> 2.1.1 (critical bug fix) -> 2.2.0
> * LTS (2020): 2.3.0 -> 2.3.1 -> 2.3.2 -> ... -> EOL(2023)
> * non-LTS (2020-2022): 2.4.0 -> 2.5.0 -> 3.0.0
> * LTS (2022): 3.1.0 -> 3.1.1 -> 3.1.2 -> ... -> EOL(2025)
>
> This LTS proposal isn't perfect and doesn't solve all possible issues,
> but I think it establishes the groundwork for future release
> plans/schedules and helps frame discussions about future releases,
> that we can work through later if needed.
>
> If there's general consensus on the basic proposal here, I can start
> updating the website after 72 hours (lazy consensus) to add the LTS
> definition and mark things on the downloads page, accordingly. If it
> turns into a significant discussion, I'll hold off on anything until
> the discussion points are resolved. If there's disagreement that can't
> be resolved, I'll start a more formal vote later (or give up due to
> lost motivation, worst case :smile:).
>
> --
> Christopher
RE: [LAZY][VOTE] A basic, but concrete, LTS proposal
Posted by "Owens, Mark" <jm...@evoforge.org>.
+1
-----Original Message-----
From: Christopher <ct...@apache.org>
Sent: Thursday, October 31, 2019 8:35 PM
To: accumulo-dev <de...@accumulo.apache.org>
Subject: Re: [LAZY][VOTE] A basic, but concrete, LTS proposal
On Thu, Oct 31, 2019 at 10:46 AM Keith Turner <ke...@deenlo.com> wrote:
>
> On Thu, Oct 31, 2019 at 10:28 AM Josh Elser <el...@apache.org> wrote:
> >
> > Seems fine to me.
> >
> > Any expectations on how upgrades work within an LTS release? How
> > about across LTS releases?
>
> The behavior I would like to see is that for any release you can
> always upgrade from the previous release. For LTS releases you can
> upgrade from two releases, the last non-LTS and last LTS release.
>
That'd be my expectation as well.
> >
> > Some specific situations to mull over:
> >
> > * Can rolling upgrade in an LTS release (to new patch version) with
> > no downtime. (e.g. 1.9.1 to 1.9.3)
Because patch releases for an LTS would be patch releases, and not major/minor bumps, I'd expect it to follow our current practice of not bumping the DATA version or the WIRE version within these. We don't guarantee rolling upgrade support today, and this doesn't change that... but it's as close as we can get I think.
> > * Can any LTS release (1.9.1) be guaranteed to upgrade to a later
> > LTS release (2.3.1)?
Because of the work involved in testing, I would expect LTS releases to be upgradable from (confirmed via testing) the latest patch release in the previous LTS line, but I wouldn't expect us to test every previous patch release in that LTS line. Because of the way we minimize/limit changes to bugfixes in patch releases already, I'd expect these combinations to work, but wouldn't expect us to test each combination. Also, patch releases can fix bugs in the upgrade process, itself, so I don't think it'd be unreasonable to expect people to be already running the latest patch before upgrading to the next LTS.
> > * What about rolling back in an LTS release (e.g. 2.3.2 back to
> > 2.3.1 after some bug is found)
We already expect that to work today, so LTS wouldn't change that. The main point of LTS is to manage our development priorities by creating more well-defined lifecycles for major/minor versions and communicating those priorities to users. It doesn't actually change what a major/minor/patch release means, though.
>
> Being able to roll back an upgrade was one motivation for the following.
>
> https://accumulo.apache.org/design/system-snapshot.html
>
> >
> > Not looking for immediate answers, but it would be good to define
> > the expectations you have around what we want Accumulo to be able to
> > do (ignoring the fact that bugs will certainly arise around
> > upgrades/downgrades).
> >
We can collect these into a FAQs section of a page describing our versioning (semver) and LTS release strategies in one place, and keep them updated as new points are raised.
> > On 10/30/19 9:00 PM, Christopher wrote:
> > > Following up from the discussion at
> > > https://lists.apache.org/thread.html/560bfe8d911be5b829e6250a34dfa
> > > 1ace0584b24251651be1c77d724@%3Cdev.accumulo.apache.org%3E
> > >
> > > I think we should adopt this LTS concept:
> > >
> > > LTS releases:
> > > * Designate a new LTS line every 2 years (designation communicates
> > > intent to support/patch)
> > > * Target patch releases to LTS lines for 3 years
> > > * EOL previous LTS line when the new one has been available for 1
> > > year
> > >
> > > non-LTS releases:
> > > * Periodic releases that aren't expected to be supported with
> > > patch releases
> > > * Can still create patch releases, but only until the next
> > > LTS/non-LTS release line (typically only for critical bugs....
> > > because we won't keep a maintenance branch around for non-LTS...
> > > instead, we'll roll bugfixes into the next release, or branch off
> > > the tag for a critical
> > > bug)
> > > * non-LTS releases are EOL as soon as the next LTS/non-LTS release
> > > line is created
> > >
> > > Transition plan:
> > >
> > > * Define LTS on the downloads page of the website
> > > * Designate 1.9 as first (and currently only) LTS release line
> > > * Mark the LTS expected EOL date on the downloads page next to the
> > > LTS releases (to the month... we don't need to get too
> > > granular/pedantic)
> > >
> > > What this proposal does *not* do is determine how frequently we
> > > release. It *only* determines which versions we will designate as LTS.
> > > So, this doesn't bind us to any fixed release schedule, and we can
> > > release as frequently (or infrequently) as our community wishes
> > > (though I hope the non-LTS releases will occur more frequently, as
> > > they can take more creative risks). But, the main point of this
> > > proposal is that every two years, we'll designate a new release
> > > that will take over as our main "supported line" that will be
> > > low-risk, and more stable over time. The 1-year overlap for people
> > > to upgrade from one LTS to the next in this plan is pretty useful, too, I think.
> > >
> > > Here's an example set of hypothetical releases (except 1.9.x and
> > > 2.0.0, which are real) under this plan:
> > >
> > > * LTS (2018): 1.9.0 -> 1.9.1 -> 1.9.2 -> ... -> EOL(2021)
> > > * non-LTS (2018-2020): 2.0.0 -> 2.1.0 -> 2.1.1 (critical bug fix)
> > > -> 2.2.0
> > > * LTS (2020): 2.3.0 -> 2.3.1 -> 2.3.2 -> ... -> EOL(2023)
> > > * non-LTS (2020-2022): 2.4.0 -> 2.5.0 -> 3.0.0
> > > * LTS (2022): 3.1.0 -> 3.1.1 -> 3.1.2 -> ... -> EOL(2025)
> > >
> > > This LTS proposal isn't perfect and doesn't solve all possible
> > > issues, but I think it establishes the groundwork for future
> > > release plans/schedules and helps frame discussions about future
> > > releases, that we can work through later if needed.
> > >
> > > If there's general consensus on the basic proposal here, I can
> > > start updating the website after 72 hours (lazy consensus) to add
> > > the LTS definition and mark things on the downloads page,
> > > accordingly. If it turns into a significant discussion, I'll hold
> > > off on anything until the discussion points are resolved. If
> > > there's disagreement that can't be resolved, I'll start a more
> > > formal vote later (or give up due to lost motivation, worst case :smile:).
> > >
> > > --
> > > Christopher
> > >
Re: [LAZY][VOTE] A basic, but concrete, LTS proposal
Posted by Christopher <ct...@apache.org>.
On Thu, Oct 31, 2019 at 10:46 AM Keith Turner <ke...@deenlo.com> wrote:
>
> On Thu, Oct 31, 2019 at 10:28 AM Josh Elser <el...@apache.org> wrote:
> >
> > Seems fine to me.
> >
> > Any expectations on how upgrades work within an LTS release? How about
> > across LTS releases?
>
> The behavior I would like to see is that for any release you can
> always upgrade from the previous release. For LTS releases you can
> upgrade from two releases, the last non-LTS and last LTS release.
>
That'd be my expectation as well.
> >
> > Some specific situations to mull over:
> >
> > * Can rolling upgrade in an LTS release (to new patch version) with no
> > downtime. (e.g. 1.9.1 to 1.9.3)
Because patch releases for an LTS would be patch releases, and not
major/minor bumps, I'd expect it to follow our current practice of not
bumping the DATA version or the WIRE version within these. We don't
guarantee rolling upgrade support today, and this doesn't change
that... but it's as close as we can get I think.
> > * Can any LTS release (1.9.1) be guaranteed to upgrade to a later LTS
> > release (2.3.1)?
Because of the work involved in testing, I would expect LTS releases
to be upgradable from (confirmed via testing) the latest patch release
in the previous LTS line, but I wouldn't expect us to test every
previous patch release in that LTS line. Because of the way we
minimize/limit changes to bugfixes in patch releases already, I'd
expect these combinations to work, but wouldn't expect us to test each
combination. Also, patch releases can fix bugs in the upgrade process,
itself, so I don't think it'd be unreasonable to expect people to be
already running the latest patch before upgrading to the next LTS.
> > * What about rolling back in an LTS release (e.g. 2.3.2 back to 2.3.1
> > after some bug is found)
We already expect that to work today, so LTS wouldn't change that. The
main point of LTS is to manage our development priorities by creating
more well-defined lifecycles for major/minor versions and
communicating those priorities to users. It doesn't actually change
what a major/minor/patch release means, though.
>
> Being able to roll back an upgrade was one motivation for the following.
>
> https://accumulo.apache.org/design/system-snapshot.html
>
> >
> > Not looking for immediate answers, but it would be good to define the
> > expectations you have around what we want Accumulo to be able to do
> > (ignoring the fact that bugs will certainly arise around
> > upgrades/downgrades).
> >
We can collect these into a FAQs section of a page describing our
versioning (semver) and LTS release strategies in one place, and keep
them updated as new points are raised.
> > On 10/30/19 9:00 PM, Christopher wrote:
> > > Following up from the discussion at
> > > https://lists.apache.org/thread.html/560bfe8d911be5b829e6250a34dfa1ace0584b24251651be1c77d724@%3Cdev.accumulo.apache.org%3E
> > >
> > > I think we should adopt this LTS concept:
> > >
> > > LTS releases:
> > > * Designate a new LTS line every 2 years (designation communicates
> > > intent to support/patch)
> > > * Target patch releases to LTS lines for 3 years
> > > * EOL previous LTS line when the new one has been available for 1 year
> > >
> > > non-LTS releases:
> > > * Periodic releases that aren't expected to be supported with patch releases
> > > * Can still create patch releases, but only until the next LTS/non-LTS
> > > release line (typically only for critical bugs.... because we won't
> > > keep a maintenance branch around for non-LTS... instead, we'll roll
> > > bugfixes into the next release, or branch off the tag for a critical
> > > bug)
> > > * non-LTS releases are EOL as soon as the next LTS/non-LTS release
> > > line is created
> > >
> > > Transition plan:
> > >
> > > * Define LTS on the downloads page of the website
> > > * Designate 1.9 as first (and currently only) LTS release line
> > > * Mark the LTS expected EOL date on the downloads page next to the LTS
> > > releases (to the month... we don't need to get too granular/pedantic)
> > >
> > > What this proposal does *not* do is determine how frequently we
> > > release. It *only* determines which versions we will designate as LTS.
> > > So, this doesn't bind us to any fixed release schedule, and we can
> > > release as frequently (or infrequently) as our community wishes
> > > (though I hope the non-LTS releases will occur more frequently, as
> > > they can take more creative risks). But, the main point of this
> > > proposal is that every two years, we'll designate a new release that
> > > will take over as our main "supported line" that will be low-risk, and
> > > more stable over time. The 1-year overlap for people to upgrade from
> > > one LTS to the next in this plan is pretty useful, too, I think.
> > >
> > > Here's an example set of hypothetical releases (except 1.9.x and
> > > 2.0.0, which are real) under this plan:
> > >
> > > * LTS (2018): 1.9.0 -> 1.9.1 -> 1.9.2 -> ... -> EOL(2021)
> > > * non-LTS (2018-2020): 2.0.0 -> 2.1.0 -> 2.1.1 (critical bug fix) -> 2.2.0
> > > * LTS (2020): 2.3.0 -> 2.3.1 -> 2.3.2 -> ... -> EOL(2023)
> > > * non-LTS (2020-2022): 2.4.0 -> 2.5.0 -> 3.0.0
> > > * LTS (2022): 3.1.0 -> 3.1.1 -> 3.1.2 -> ... -> EOL(2025)
> > >
> > > This LTS proposal isn't perfect and doesn't solve all possible issues,
> > > but I think it establishes the groundwork for future release
> > > plans/schedules and helps frame discussions about future releases,
> > > that we can work through later if needed.
> > >
> > > If there's general consensus on the basic proposal here, I can start
> > > updating the website after 72 hours (lazy consensus) to add the LTS
> > > definition and mark things on the downloads page, accordingly. If it
> > > turns into a significant discussion, I'll hold off on anything until
> > > the discussion points are resolved. If there's disagreement that can't
> > > be resolved, I'll start a more formal vote later (or give up due to
> > > lost motivation, worst case :smile:).
> > >
> > > --
> > > Christopher
> > >
Re: [LAZY][VOTE] A basic, but concrete, LTS proposal
Posted by Keith Turner <ke...@deenlo.com>.
On Thu, Oct 31, 2019 at 10:28 AM Josh Elser <el...@apache.org> wrote:
>
> Seems fine to me.
>
> Any expectations on how upgrades work within an LTS release? How about
> across LTS releases?
The behavior I would like to see is that for any release you can
always upgrade from the previous release. For LTS releases you can
upgrade from two releases, the last non-LTS and last LTS release.
>
> Some specific situations to mull over:
>
> * Can rolling upgrade in an LTS release (to new patch version) with no
> downtime. (e.g. 1.9.1 to 1.9.3)
> * Can any LTS release (1.9.1) be guaranteed to upgrade to a later LTS
> release (2.3.1)?
> * What about rolling back in an LTS release (e.g. 2.3.2 back to 2.3.1
> after some bug is found)
Being able to roll back an upgrade was one motivation for the following.
https://accumulo.apache.org/design/system-snapshot.html
>
> Not looking for immediate answers, but it would be good to define the
> expectations you have around what we want Accumulo to be able to do
> (ignoring the fact that bugs will certainly arise around
> upgrades/downgrades).
>
> On 10/30/19 9:00 PM, Christopher wrote:
> > Following up from the discussion at
> > https://lists.apache.org/thread.html/560bfe8d911be5b829e6250a34dfa1ace0584b24251651be1c77d724@%3Cdev.accumulo.apache.org%3E
> >
> > I think we should adopt this LTS concept:
> >
> > LTS releases:
> > * Designate a new LTS line every 2 years (designation communicates
> > intent to support/patch)
> > * Target patch releases to LTS lines for 3 years
> > * EOL previous LTS line when the new one has been available for 1 year
> >
> > non-LTS releases:
> > * Periodic releases that aren't expected to be supported with patch releases
> > * Can still create patch releases, but only until the next LTS/non-LTS
> > release line (typically only for critical bugs.... because we won't
> > keep a maintenance branch around for non-LTS... instead, we'll roll
> > bugfixes into the next release, or branch off the tag for a critical
> > bug)
> > * non-LTS releases are EOL as soon as the next LTS/non-LTS release
> > line is created
> >
> > Transition plan:
> >
> > * Define LTS on the downloads page of the website
> > * Designate 1.9 as first (and currently only) LTS release line
> > * Mark the LTS expected EOL date on the downloads page next to the LTS
> > releases (to the month... we don't need to get too granular/pedantic)
> >
> > What this proposal does *not* do is determine how frequently we
> > release. It *only* determines which versions we will designate as LTS.
> > So, this doesn't bind us to any fixed release schedule, and we can
> > release as frequently (or infrequently) as our community wishes
> > (though I hope the non-LTS releases will occur more frequently, as
> > they can take more creative risks). But, the main point of this
> > proposal is that every two years, we'll designate a new release that
> > will take over as our main "supported line" that will be low-risk, and
> > more stable over time. The 1-year overlap for people to upgrade from
> > one LTS to the next in this plan is pretty useful, too, I think.
> >
> > Here's an example set of hypothetical releases (except 1.9.x and
> > 2.0.0, which are real) under this plan:
> >
> > * LTS (2018): 1.9.0 -> 1.9.1 -> 1.9.2 -> ... -> EOL(2021)
> > * non-LTS (2018-2020): 2.0.0 -> 2.1.0 -> 2.1.1 (critical bug fix) -> 2.2.0
> > * LTS (2020): 2.3.0 -> 2.3.1 -> 2.3.2 -> ... -> EOL(2023)
> > * non-LTS (2020-2022): 2.4.0 -> 2.5.0 -> 3.0.0
> > * LTS (2022): 3.1.0 -> 3.1.1 -> 3.1.2 -> ... -> EOL(2025)
> >
> > This LTS proposal isn't perfect and doesn't solve all possible issues,
> > but I think it establishes the groundwork for future release
> > plans/schedules and helps frame discussions about future releases,
> > that we can work through later if needed.
> >
> > If there's general consensus on the basic proposal here, I can start
> > updating the website after 72 hours (lazy consensus) to add the LTS
> > definition and mark things on the downloads page, accordingly. If it
> > turns into a significant discussion, I'll hold off on anything until
> > the discussion points are resolved. If there's disagreement that can't
> > be resolved, I'll start a more formal vote later (or give up due to
> > lost motivation, worst case :smile:).
> >
> > --
> > Christopher
> >
Re: [LAZY][VOTE] A basic, but concrete, LTS proposal
Posted by Jeffrey Manno <je...@gmail.com>.
I am in favor of the LTS release schedule. I find that having a more
structured but still flexible plan for releases benefits both the users of
accumulo and developers as it gives us more defined trajectory on how to
reach certain goals.
My only issue with some LTS release projects is that sometimes the project
feels more stagnant since major updates are generally slowed in favor of
supporting the stable release instead of the non-LTS releases. Though with
this being a open-source and collaborative project, I don't worry about
that part too much.
On Thu, Oct 31, 2019 at 10:28 AM Josh Elser <el...@apache.org> wrote:
> Seems fine to me.
>
> Any expectations on how upgrades work within an LTS release? How about
> across LTS releases?
>
> Some specific situations to mull over:
>
> * Can rolling upgrade in an LTS release (to new patch version) with no
> downtime. (e.g. 1.9.1 to 1.9.3)
> * Can any LTS release (1.9.1) be guaranteed to upgrade to a later LTS
> release (2.3.1)?
> * What about rolling back in an LTS release (e.g. 2.3.2 back to 2.3.1
> after some bug is found)
>
> Not looking for immediate answers, but it would be good to define the
> expectations you have around what we want Accumulo to be able to do
> (ignoring the fact that bugs will certainly arise around
> upgrades/downgrades).
>
> On 10/30/19 9:00 PM, Christopher wrote:
> > Following up from the discussion at
> >
> https://lists.apache.org/thread.html/560bfe8d911be5b829e6250a34dfa1ace0584b24251651be1c77d724@%3Cdev.accumulo.apache.org%3E
> >
> > I think we should adopt this LTS concept:
> >
> > LTS releases:
> > * Designate a new LTS line every 2 years (designation communicates
> > intent to support/patch)
> > * Target patch releases to LTS lines for 3 years
> > * EOL previous LTS line when the new one has been available for 1 year
> >
> > non-LTS releases:
> > * Periodic releases that aren't expected to be supported with patch
> releases
> > * Can still create patch releases, but only until the next LTS/non-LTS
> > release line (typically only for critical bugs.... because we won't
> > keep a maintenance branch around for non-LTS... instead, we'll roll
> > bugfixes into the next release, or branch off the tag for a critical
> > bug)
> > * non-LTS releases are EOL as soon as the next LTS/non-LTS release
> > line is created
> >
> > Transition plan:
> >
> > * Define LTS on the downloads page of the website
> > * Designate 1.9 as first (and currently only) LTS release line
> > * Mark the LTS expected EOL date on the downloads page next to the LTS
> > releases (to the month... we don't need to get too granular/pedantic)
> >
> > What this proposal does *not* do is determine how frequently we
> > release. It *only* determines which versions we will designate as LTS.
> > So, this doesn't bind us to any fixed release schedule, and we can
> > release as frequently (or infrequently) as our community wishes
> > (though I hope the non-LTS releases will occur more frequently, as
> > they can take more creative risks). But, the main point of this
> > proposal is that every two years, we'll designate a new release that
> > will take over as our main "supported line" that will be low-risk, and
> > more stable over time. The 1-year overlap for people to upgrade from
> > one LTS to the next in this plan is pretty useful, too, I think.
> >
> > Here's an example set of hypothetical releases (except 1.9.x and
> > 2.0.0, which are real) under this plan:
> >
> > * LTS (2018): 1.9.0 -> 1.9.1 -> 1.9.2 -> ... -> EOL(2021)
> > * non-LTS (2018-2020): 2.0.0 -> 2.1.0 -> 2.1.1 (critical bug fix) ->
> 2.2.0
> > * LTS (2020): 2.3.0 -> 2.3.1 -> 2.3.2 -> ... -> EOL(2023)
> > * non-LTS (2020-2022): 2.4.0 -> 2.5.0 -> 3.0.0
> > * LTS (2022): 3.1.0 -> 3.1.1 -> 3.1.2 -> ... -> EOL(2025)
> >
> > This LTS proposal isn't perfect and doesn't solve all possible issues,
> > but I think it establishes the groundwork for future release
> > plans/schedules and helps frame discussions about future releases,
> > that we can work through later if needed.
> >
> > If there's general consensus on the basic proposal here, I can start
> > updating the website after 72 hours (lazy consensus) to add the LTS
> > definition and mark things on the downloads page, accordingly. If it
> > turns into a significant discussion, I'll hold off on anything until
> > the discussion points are resolved. If there's disagreement that can't
> > be resolved, I'll start a more formal vote later (or give up due to
> > lost motivation, worst case :smile:).
> >
> > --
> > Christopher
> >
>
Re: [LAZY][VOTE] A basic, but concrete, LTS proposal
Posted by Josh Elser <el...@apache.org>.
Seems fine to me.
Any expectations on how upgrades work within an LTS release? How about
across LTS releases?
Some specific situations to mull over:
* Can rolling upgrade in an LTS release (to new patch version) with no
downtime. (e.g. 1.9.1 to 1.9.3)
* Can any LTS release (1.9.1) be guaranteed to upgrade to a later LTS
release (2.3.1)?
* What about rolling back in an LTS release (e.g. 2.3.2 back to 2.3.1
after some bug is found)
Not looking for immediate answers, but it would be good to define the
expectations you have around what we want Accumulo to be able to do
(ignoring the fact that bugs will certainly arise around
upgrades/downgrades).
On 10/30/19 9:00 PM, Christopher wrote:
> Following up from the discussion at
> https://lists.apache.org/thread.html/560bfe8d911be5b829e6250a34dfa1ace0584b24251651be1c77d724@%3Cdev.accumulo.apache.org%3E
>
> I think we should adopt this LTS concept:
>
> LTS releases:
> * Designate a new LTS line every 2 years (designation communicates
> intent to support/patch)
> * Target patch releases to LTS lines for 3 years
> * EOL previous LTS line when the new one has been available for 1 year
>
> non-LTS releases:
> * Periodic releases that aren't expected to be supported with patch releases
> * Can still create patch releases, but only until the next LTS/non-LTS
> release line (typically only for critical bugs.... because we won't
> keep a maintenance branch around for non-LTS... instead, we'll roll
> bugfixes into the next release, or branch off the tag for a critical
> bug)
> * non-LTS releases are EOL as soon as the next LTS/non-LTS release
> line is created
>
> Transition plan:
>
> * Define LTS on the downloads page of the website
> * Designate 1.9 as first (and currently only) LTS release line
> * Mark the LTS expected EOL date on the downloads page next to the LTS
> releases (to the month... we don't need to get too granular/pedantic)
>
> What this proposal does *not* do is determine how frequently we
> release. It *only* determines which versions we will designate as LTS.
> So, this doesn't bind us to any fixed release schedule, and we can
> release as frequently (or infrequently) as our community wishes
> (though I hope the non-LTS releases will occur more frequently, as
> they can take more creative risks). But, the main point of this
> proposal is that every two years, we'll designate a new release that
> will take over as our main "supported line" that will be low-risk, and
> more stable over time. The 1-year overlap for people to upgrade from
> one LTS to the next in this plan is pretty useful, too, I think.
>
> Here's an example set of hypothetical releases (except 1.9.x and
> 2.0.0, which are real) under this plan:
>
> * LTS (2018): 1.9.0 -> 1.9.1 -> 1.9.2 -> ... -> EOL(2021)
> * non-LTS (2018-2020): 2.0.0 -> 2.1.0 -> 2.1.1 (critical bug fix) -> 2.2.0
> * LTS (2020): 2.3.0 -> 2.3.1 -> 2.3.2 -> ... -> EOL(2023)
> * non-LTS (2020-2022): 2.4.0 -> 2.5.0 -> 3.0.0
> * LTS (2022): 3.1.0 -> 3.1.1 -> 3.1.2 -> ... -> EOL(2025)
>
> This LTS proposal isn't perfect and doesn't solve all possible issues,
> but I think it establishes the groundwork for future release
> plans/schedules and helps frame discussions about future releases,
> that we can work through later if needed.
>
> If there's general consensus on the basic proposal here, I can start
> updating the website after 72 hours (lazy consensus) to add the LTS
> definition and mark things on the downloads page, accordingly. If it
> turns into a significant discussion, I'll hold off on anything until
> the discussion points are resolved. If there's disagreement that can't
> be resolved, I'll start a more formal vote later (or give up due to
> lost motivation, worst case :smile:).
>
> --
> Christopher
>