Re: [VOTE] Proposal to release version 1.10

[Christopher]

+1 to creating a 1.10.0 derived from 1.9 that bumps the Java
requirement to 8, and doing so instead of releasing 1.9.4.

I think the java version bump will help with maintaining patches that
can be more easily backported to 1.x. If this vote passes, I will
advocate for 1.10 to be used as the LTS instead of 1.9 in the LTS
discussion.

On Thu, Oct 31, 2019 at 8:37 PM Ed Coleman  wrote:
>
> As suggested in the LTS discussion ([LAZY][VOTE] A basic, but concrete, LTS
> proposal), I'm breaking this out to as a separate thread to keep the topic
> distinct.
>
>
> The proposal - I would like to start the formal release process for a 1.10
> version that would change the java language level to java 8.  The release
> would be based on the current 1.9 branch and would be released instead of a
> 1.9.4.  The 1.10 release would not contain additional feature changes that
> are not present in the current 1.9 branch. Currently, this would be based
> on the commit SHA:
>
>
> 328ffa0849981e0f113dfbf539c832b447e06902 - committed Thu Oct 10.
>
>
> (I am unaware of any bug-fixes or issues in the pipe line that would /
> should be included - but hopefully this makes the intention clear.)
>
>
> The goal is to provide a candidate for LTS nomination that is based on the
> current 1.9.x code, but unifies our currently supported branches to all use
> java 8 as the supported language level. While this had been discussed in
> the past, enough time has passed that a java 8 requirement now, seems to
> me, to be unlikely to impact any customers that would look to upgrade
> Accumulo past a 1.9.3 version and have them not running at least java 8.
> Having our code base with a modern, unified java language support level
> would greatly benefit our development and reduce the burden to support our
> multiple branches.
>
>
> This vote will be held open for at least the standard 72 hours.

[VOTE] Proposal to release version 1.10

[Ed Coleman]

As suggested in the LTS discussion ([LAZY][VOTE] A basic, but concrete, LTS
proposal), I'm breaking this out to as a separate thread to keep the topic
distinct.


The proposal - I would like to start the formal release process for a 1.10
version that would change the java language level to java 8.  The release
would be based on the current 1.9 branch and would be released instead of a
1.9.4.  The 1.10 release would not contain additional feature changes that
are not present in the current 1.9 branch. Currently, this would be based
on the commit SHA:


328ffa0849981e0f113dfbf539c832b447e06902 - committed Thu Oct 10.


(I am unaware of any bug-fixes or issues in the pipe line that would /
should be included - but hopefully this makes the intention clear.)


The goal is to provide a candidate for LTS nomination that is based on the
current 1.9.x code, but unifies our currently supported branches to all use
java 8 as the supported language level. While this had been discussed in
the past, enough time has passed that a java 8 requirement now, seems to
me, to be unlikely to impact any customers that would look to upgrade
Accumulo past a 1.9.3 version and have them not running at least java 8.
Having our code base with a modern, unified java language support level
would greatly benefit our development and reduce the burden to support our
multiple branches.


This vote will be held open for at least the standard 72 hours.

Re: [LAZY][VOTE] A basic, but concrete, LTS proposal

[Christopher]

On Thu, Oct 31, 2019 at 10:46 AM Keith Turner  wrote:
>
> On Thu, Oct 31, 2019 at 10:28 AM Josh Elser  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 -> 

Re: [LAZY][VOTE] A basic, but concrete, LTS proposal

[Christopher]

I see your point about 1.10 and the difficulty of upgrading to 2.x and
Hadoop 3. I would be in favor of doing a release of 1.10 and releasing
that as the first LTS to replace 1.9 if we limit the changes between
1.9 and 1.10 to the following:

1. Update Java minimum requirements to Java 8
2. Make Hadoop 3 the default in the build instead of Hadoop 2 (but
still support Hadoop 2 builds) [negotiable]

This assumes we would release 1.10.0 *very* soon, and that we don't
make any other changes (build/release tooling to facilitate a release
being the exception). This also assumes we would abandon a 1.9.4
release and release those bug fixes in 1.10.0 instead.

If we do this, I think we'd probably want to shorten the 3 year
support window a little bit for 1.10 (maybe 18 or 24 months, but we
still EOL around 1 year after the next LTS), so we don't end up
overlapping with too many LTS releases in the future we're
simultaneously supporting... but just for this first one.

The one roadblock that I see to the 1.10 LTS proposal would be that we
have already litigated the decision to move to Java 8 several times in
the past, and it was previously agreed that this change would occur in
2.x, and *not* in 1.x. If you wish to have 1.10 as the LTS with Java
8, I think you should do a [VOTE] thread in the dev list to ensure
community consensus on that, before moving forward here.

On Thu, Oct 31, 2019 at 12:48 PM Ed Coleman  wrote:
>
> Another dimension to this discussion that I'd like to address is the
> provision for a 1.10 version.  In fact, I lean towards having 1.10
> nominated as the pre-2.x LTS version instead of a 1.9.x.  I am in favor of
> the basic LTS proposal, but I think that additional accommodations to ease
> the pre-2.x to a 2.x upgrade path must be considered before any adoption of
> an LTS plan.
>
> The largest change that I'd like to propose for 1.10 is that the minimum
> Java language version be bumped to java 8 so that merging code between
> versions can use the same language constructs.  As it is now, code written
> for 1.9.x cannot use lambda, streams,... all of the "modern" features.
> Merging the code forward, one is left with the option of not using those
> features, or changing the code which, if not done perfectly, could
> introduce a different set of bugs between versions.  Likewise, if someone
> wanted to back port a feature from 2.x into the 1.9.x code base, additional
> changes, beyond those required because of 2.x restructuring are likely to
> be necessary.
>
> The migration from Accumulo 1.9.x to a 2.x is not straight forward and will
> require changes to Accumulo clients. However, the largest obstacle to
> upgrading to 2.x is with the Hadoop 3 requirement.  This is a major,
> non-trival requirement change that is going to take significant effort (and
> time) for a large-scale deployments to develop to and then upgrade to
> Hadoop 3.  There is going to be significant work required to adequately
> test necessary client changes, and then upgrade the deployed systems, first
> to Hadoop 3 and then to Accumulo 2.x. And until they can, they are going to
> be on a pre-2.x Accumulo version.
>
> With code frozen at 1.9.x, large deployments are going to need to make some
> hard decisions - do they continue to use 1.9.x as released, or do they make
> some patched Frankenstein version?  If they find that they aggressively
> need to patch to get features that improve current operations, how much
> additional work is going to be required if / when they are in a position to
> upgrade? How much of that work would further delay upgrading to Hadoop 3 /
> Accumulo 2.x?
>
> Having features released by the community eases support across the whole
> ecosystem. We will all have access to the same code base, the code will be
> exercised by the continuous integration tests, and it provides greater
> insurance that those features will be available once an upgrade to 2.x is
> possible. Otherwise, reasoning about what "version" is actually running and
> what that implies when requesting support from the community is just that
> much harder for everyone.
>
> My opinion is that if we can accommodate some feature improvements as
> groups work to adopting a Hadoop 3 / 2.x deployment, then we can reduce the
> work required across the community and the users, work that freezing at
> 1.9.x for pre-2.x would introduce an additional burdens on the users.
>
> I am in favor of adopting an LTS, but I think we really need to consider
> the impact of requiring Hadoop 3 is having on upgrading to Accumulo 2.x in
> the LTS plan.

Re: [LAZY][VOTE] A basic, but concrete, LTS proposal

[Jeffrey Manno]

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

[Keith Turner]

On Thu, Oct 31, 2019 at 10:28 AM Josh Elser  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

[Josh Elser]

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

[Keith Turner]

+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  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: Introduction: Arvind Shyamsundar

[Keith Turner]

Welcome Arvind. I would be interested in reading about your
experiences with Accumulo on Azure.

On Mon, Oct 28, 2019 at 7:21 PM Arvind Shyamsundar
 wrote:
>
> Hello!
> I'm Arvind Shyamsundar and I work at Microsoft. I'm located in Redmond, WA. 
> Along with a few colleagues, we have been working on validating and hopefully 
> making Microsoft Azure a great place to run Accumulo. I made my first formal 
> contribution to Accumulo today (via. a PR for accumulo-testing) - hopefully 
> that is the start of a long and fruitful association with this community!
>
> Thank you!
>
> - Arvind
> GitHub: 
> https://github.com/arvindshmicrosoft