Towards a 2.1 release

Discussion:

Remko Popma

2014-09-22 16:01:27 UTC

Do we need to have a 2.1-beta release, or shall we just do a 2.1 release
(and follow up with 2.1.1 etc if issues are found)?

When are we aiming to do this release?

There are still ~10 open Jira tickets targetting 2.1.
Please take a look to see if that list is up to date.

Gary Gregory

2014-09-22 17:00:52 UTC

Permalink

I think it is a matter of confidence.

The API module is solid.

If something outside of the API needs fixing, we can do so quickly without
worrying about being handcuffed by BC.

Since I am not the RM I would suggest a beta this week and 2.1 within 1
week after. Folks that are paying attention will play with the beta, others
that are not can get 2.1.

A 2.1 w/o a beta would be OK by me for the non-handcuffed reasons stated
above.

If at some later point, lots of 3rd parties end up relying on a stable Core
module, we can worry about marking what is really public in Core vs. not.

Gary

Post by Remko Popma
Do we need to have a 2.1-beta release, or shall we just do a 2.1 release
(and follow up with 2.1.1 etc if issues are found)?
When are we aiming to do this release?
There are still ~10 open Jira tickets targetting 2.1.
Please take a look to see if that list is up to date.

--
E-Mail: ***@gmail.com | ***@apache.org
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Matt Sicker

2014-09-22 17:01:00 UTC

Permalink

Unless we have some way to have more than one release on the site, making
it 2.1 might be our best bet.

--
Matt Sicker <***@gmail.com>

Remko Popma

2014-09-22 17:15:49 UTC

Permalink

I'm also fine with just doing a 2.1 and following up with 2.1.x releases if
issues are found.

Post by Matt Sicker
Unless we have some way to have more than one release on the site, making
it 2.1 might be our best bet.

Matt Sicker

2014-09-22 18:16:35 UTC

Permalink

How would I even be able to release the beta artifacts? The "release"
profile doesn't seem appropriate.

Post by Remko Popma
I'm also fine with just doing a 2.1 and following up with 2.1.x releases
if issues are found.

Post by Matt Sicker
Unless we have some way to have more than one release on the site, making
it 2.1 might be our best bet.

--
Matt Sicker <***@gmail.com>

Gary Gregory

2014-09-22 18:43:46 UTC

Permalink

I guess you'll need Ralph's help on how he did it before.

Gary

Post by Matt Sicker
How would I even be able to release the beta artifacts? The "release"
profile doesn't seem appropriate.

Post by Remko Popma
I'm also fine with just doing a 2.1 and following up with 2.1.x releases
if issues are found.

Post by Matt Sicker
Unless we have some way to have more than one release on the site,
making it 2.1 might be our best bet.

Post by Remko Popma
Do we need to have a 2.1-beta release, or shall we just do a 2.1
release (and follow up with 2.1.1 etc if issues are found)?
When are we aiming to do this release?
There are still ~10 open Jira tickets targetting 2.1.
Please take a look to see if that list is up to date.

Gary Gregory

2014-09-22 23:25:08 UTC

Permalink

Matt,

It seems like the consensus is to skip a beta.

You may want to send a [poll] email and get a more formal feel for it.

Gary

Post by Matt Sicker
How would I even be able to release the beta artifacts? The "release"
profile doesn't seem appropriate.

Post by Remko Popma
I'm also fine with just doing a 2.1 and following up with 2.1.x releases
if issues are found.

Post by Matt Sicker
Unless we have some way to have more than one release on the site,
making it 2.1 might be our best bet.

Post by Remko Popma
Do we need to have a 2.1-beta release, or shall we just do a 2.1
release (and follow up with 2.1.1 etc if issues are found)?
When are we aiming to do this release?
There are still ~10 open Jira tickets targetting 2.1.
Please take a look to see if that list is up to date.

Remko Popma

2014-09-23 00:25:23 UTC

Permalink

Gary mentioned that in Commons they have multiple versions on the site so he suggested using that profile/maven plugin. That said, this may not be easy and will probably be significant work.

As Gary said, we're all in agreement we can do a 2.1 release, so there's no need to look into the implications of the beta idea further.

Are there any items we still want to include in this release?

Sent from my iPhone

Post by Gary Gregory
Matt,
It seems like the consensus is to skip a beta.
You may want to send a [poll] email and get a more formal feel for it.
Gary

How would I even be able to release the beta artifacts? The "release" profile doesn't seem appropriate.

I'm also fine with just doing a 2.1 and following up with 2.1.x releases if issues are found.

Unless we have some way to have more than one release on the site, making it 2.1 might be our best bet.

Do we need to have a 2.1-beta release, or shall we just do a 2.1 release (and follow up with 2.1.1 etc if issues are found)?
When are we aiming to do this release?
There are still ~10 open Jira tickets targetting 2.1.
Please take a look to see if that list is up to date.

--
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Matt Sicker

2014-09-23 15:38:12 UTC

Permalink

I know that the work I was doing on log4j-web can wait for 2.2, so no
objections for going ahead with 2.1 from me.

Post by Remko Popma
Gary mentioned that in Commons they have multiple versions on the site so
he suggested using that profile/maven plugin. That said, this may not be
easy and will probably be significant work.
As Gary said, we're all in agreement we can do a 2.1 release, so there's
no need to look into the implications of the beta idea further.
Are there any items we still want to include in this release?
Sent from my iPhone
Matt,
It seems like the consensus is to skip a beta.
You may want to send a [poll] email and get a more formal feel for it.
Gary

Post by Matt Sicker
How would I even be able to release the beta artifacts? The "release"
profile doesn't seem appropriate.

Post by Remko Popma
I'm also fine with just doing a 2.1 and following up with 2.1.x releases
if issues are found.

Post by Matt Sicker
Unless we have some way to have more than one release on the site,
making it 2.1 might be our best bet.

Post by Remko Popma
Do we need to have a 2.1-beta release, or shall we just do a 2.1
release (and follow up with 2.1.1 etc if issues are found)?
When are we aiming to do this release?
There are still ~10 open Jira tickets targetting 2.1.
Please take a look to see if that list is up to date.

--
Java Persistence with Hibernate, Second Edition
<http://www.manning.com/bauer3/>
JUnit in Action, Second Edition <http://www.manning.com/tahchiev/>
Spring Batch in Action <http://www.manning.com/templier/>
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

--
Matt Sicker <***@gmail.com>

Gary Gregory

2014-09-23 15:43:28 UTC

Permalink

Perhaps we can all take time until this weekend to clean up and polish
before you cut an RC... on Friday?

Gary

Post by Matt Sicker
I know that the work I was doing on log4j-web can wait for 2.2, so no
objections for going ahead with 2.1 from me.

Post by Matt Sicker
How would I even be able to release the beta artifacts? The "release"
profile doesn't seem appropriate.

Post by Remko Popma
I'm also fine with just doing a 2.1 and following up with 2.1.x
releases if issues are found.

Post by Matt Sicker
Unless we have some way to have more than one release on the site,
making it 2.1 might be our best bet.

Post by Remko Popma
Do we need to have a 2.1-beta release, or shall we just do a 2.1
release (and follow up with 2.1.1 etc if issues are found)?
When are we aiming to do this release?
There are still ~10 open Jira tickets targetting 2.1.
Please take a look to see if that list is up to date.

Ralph Goers

2014-09-23 16:40:18 UTC

Permalink

A beta release is exactly the same as a regular release. Just change the version in the pom to 2.1-beta1.

As for getting multiple versions on the site, other projects do that. Maven does it for older versions. It should just be a matter of copying the template they use.

IMO the only reason to do a beta is if their are new features that we consider to be not-quite-ready for production. On the other hand, I consider an RC to be believed to be production ready but requiring additional feedback. FWIW - I find RCs a bit confusing since we vote on a release candidate with every release.

Ralph

Perhaps we can all take time until this weekend to clean up and polish before you cut an RC... on Friday?
Gary
I know that the work I was doing on log4j-web can wait for 2.2, so no objections for going ahead with 2.1 from me.
Gary mentioned that in Commons they have multiple versions on the site so he suggested using that profile/maven plugin. That said, this may not be easy and will probably be significant work.
As Gary said, we're all in agreement we can do a 2.1 release, so there's no need to look into the implications of the beta idea further.
Are there any items we still want to include in this release?
Sent from my iPhone

Post by Gary Gregory
Matt,
It seems like the consensus is to skip a beta.
You may want to send a [poll] email and get a more formal feel for it.
Gary
How would I even be able to release the beta artifacts? The "release" profile doesn't seem appropriate.
I'm also fine with just doing a 2.1 and following up with 2.1.x releases if issues are found.
Unless we have some way to have more than one release on the site, making it 2.1 might be our best bet.
Do we need to have a 2.1-beta release, or shall we just do a 2.1 release (and follow up with 2.1.1 etc if issues are found)?
When are we aiming to do this release?
There are still ~10 open Jira tickets targetting 2.1.
Please take a look to see if that list is up to date.
--
--
--
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

--
--
Java Persistence with Hibernate, Second Edition
JUnit in Action, Second Edition
Spring Batch in Action
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory

Matt Sicker

2014-09-23 17:52:02 UTC

Permalink

Maybe we can call the "release candidate" a "candidate release", while the
traditional RC is still an RC. So in this case, we do CRs for the official
release (which I believe was how you suggested naming tags).

A beta release is exactly the same as a âregularâ release. Just change the
version in the pom to 2.1-beta1.
As for getting multiple versions on the site, other projects do that.
Maven does it for older versions. It should just be a matter of copying
the template they use.
IMO the only reason to do a beta is if their are new features that we
consider to be not-quite-ready for production. On the other hand, I
consider an RC to be believed to be production ready but requiring
additional feedback. FWIW - I find RCs a bit confusing since we vote on a
ârelease candidateâ with every release.
Ralph
Perhaps we can all take time until this weekend to clean up and polish
before you cut an RC... on Friday?
Gary

Post by Matt Sicker
I know that the work I was doing on log4j-web can wait for 2.2, so no
objections for going ahead with 2.1 from me.

Post by Remko Popma
Gary mentioned that in Commons they have multiple versions on the site
so he suggested using that profile/maven plugin. That said, this may not be
easy and will probably be significant work.
As Gary said, we're all in agreement we can do a 2.1 release, so there's
no need to look into the implications of the beta idea further.
Are there any items we still want to include in this release?
Sent from my iPhone
Matt,
It seems like the consensus is to skip a beta.
You may want to send a [poll] email and get a more formal feel for it.
Gary

Post by Matt Sicker
How would I even be able to release the beta artifacts? The "release"
profile doesn't seem appropriate.

Post by Remko Popma
I'm also fine with just doing a 2.1 and following up with 2.1.x
releases if issues are found.

Post by Matt Sicker
Unless we have some way to have more than one release on the site,
making it 2.1 might be our best bet.

Post by Remko Popma
Do we need to have a 2.1-beta release, or shall we just do a 2.1
release (and follow up with 2.1.1 etc if issues are found)?
When are we aiming to do this release?
There are still ~10 open Jira tickets targetting 2.1.
Please take a look to see if that list is up to date.

--
Matt Sicker <***@gmail.com>

Gary Gregory

2014-09-23 18:02:01 UTC

Permalink

Confusing! What's wrong with Alpha, Beta and Release? A release candidate
is our internal bits before it gets to A, B, or R.

Gary

Post by Matt Sicker
Maybe we can call the "release candidate" a "candidate release", while the
traditional RC is still an RC. So in this case, we do CRs for the official
release (which I believe was how you suggested naming tags).

A beta release is exactly the same as a âregularâ release. Just change
the version in the pom to 2.1-beta1.
As for getting multiple versions on the site, other projects do that.
Maven does it for older versions. It should just be a matter of copying
the template they use.
IMO the only reason to do a beta is if their are new features that we
consider to be not-quite-ready for production. On the other hand, I
consider an RC to be believed to be production ready but requiring
additional feedback. FWIW - I find RCs a bit confusing since we vote on a
ârelease candidateâ with every release.
Ralph
Perhaps we can all take time until this weekend to clean up and polish
before you cut an RC... on Friday?
Gary

Post by Matt Sicker
I know that the work I was doing on log4j-web can wait for 2.2, so no
objections for going ahead with 2.1 from me.

Post by Remko Popma
Gary mentioned that in Commons they have multiple versions on the site
so he suggested using that profile/maven plugin. That said, this may not be
easy and will probably be significant work.
As Gary said, we're all in agreement we can do a 2.1 release, so
there's no need to look into the implications of the beta idea further.
Are there any items we still want to include in this release?
Sent from my iPhone
Matt,
It seems like the consensus is to skip a beta.
You may want to send a [poll] email and get a more formal feel for it.
Gary

Post by Matt Sicker
How would I even be able to release the beta artifacts? The "release"
profile doesn't seem appropriate.

Post by Remko Popma
I'm also fine with just doing a 2.1 and following up with 2.1.x
releases if issues are found.

Post by Matt Sicker
Unless we have some way to have more than one release on the site,
making it 2.1 might be our best bet.

Post by Remko Popma
Do we need to have a 2.1-beta release, or shall we just do a 2.1
release (and follow up with 2.1.1 etc if issues are found)?
When are we aiming to do this release?
There are still ~10 open Jira tickets targetting 2.1.
Please take a look to see if that list is up to date.

Ralph Goers

2014-09-23 21:30:36 UTC

Permalink

When you do a release that release has to be voted on - which makes it a release candidate. If it is not approved than the candidate fails, you fix whatever problems there were and move on to the next candidate. In short, it is something that is just part of the release process for a specific release. It doesnt really belong in the artifact id and/or version. It may need to be represented in the source repository, but that is difficult to do with Maven.

The notion of Alpha or Beta denotes the expected stability of the release.

Ralph

Confusing! What's wrong with Alpha, Beta and Release? A release candidate is our internal bits before it gets to A, B, or R.
Gary
Maybe we can call the "release candidate" a "candidate release", while the traditional RC is still an RC. So in this case, we do CRs for the official release (which I believe was how you suggested naming tags).
A beta release is exactly the same as a regular release. Just change the version in the pom to 2.1-beta1.
As for getting multiple versions on the site, other projects do that. Maven does it for older versions. It should just be a matter of copying the template they use.
IMO the only reason to do a beta is if their are new features that we consider to be not-quite-ready for production. On the other hand, I consider an RC to be believed to be production ready but requiring additional feedback. FWIW - I find RCs a bit confusing since we vote on a release candidate with every release.
Ralph

Matt Sicker

2014-09-24 13:14:04 UTC

Permalink

That's why I thought calling it a "candidate" release made that
distinction. Plus, Alpha, Beta, Candidate release. Going ABC like that
makes suffixes like Final or Release both come next, though that's not an
issue here.

Post by Ralph Goers
When you do a release that release has to be voted on - which makes it a
release âcandidateâ. If it is not approved than the candidate fails, you
fix whatever problems there were and move on to the next candidate. In
short, it is something that is just part of the release process for a
specific release. It doesnât really belong in the artifact id and/or
version. It may need to be represented in the source repository, but that
is difficult to do with Maven.
The notion of Alpha or Beta denotes the expected stability of the release.
Ralph
Confusing! What's wrong with Alpha, Beta and Release? A release candidate
is our internal bits before it gets to A, B, or R.
Gary

Post by Matt Sicker
Maybe we can call the "release candidate" a "candidate release", while
the traditional RC is still an RC. So in this case, we do CRs for the
official release (which I believe was how you suggested naming tags).

A beta release is exactly the same as a âregularâ release. Just change
the version in the pom to 2.1-beta1.
As for getting multiple versions on the site, other projects do that.
Maven does it for older versions. It should just be a matter of copying
the template they use.
IMO the only reason to do a beta is if their are new features that we
consider to be not-quite-ready for production. On the other hand, I
consider an RC to be believed to be production ready but requiring
additional feedback. FWIW - I find RCs a bit confusing since we vote on a
ârelease candidateâ with every release.
Ralph
Perhaps we can all take time until this weekend to clean up and polish
before you cut an RC... on Friday?
Gary

Post by Matt Sicker
I know that the work I was doing on log4j-web can wait for 2.2, so no
objections for going ahead with 2.1 from me.

Post by Remko Popma
Gary mentioned that in Commons they have multiple versions on the site
so he suggested using that profile/maven plugin. That said, this may not be
easy and will probably be significant work.
As Gary said, we're all in agreement we can do a 2.1 release, so
there's no need to look into the implications of the beta idea further.
Are there any items we still want to include in this release?
Sent from my iPhone
Matt,
It seems like the consensus is to skip a beta.
You may want to send a [poll] email and get a more formal feel for it.
Gary

Post by Matt Sicker
How would I even be able to release the beta artifacts? The "release"
profile doesn't seem appropriate.

Post by Remko Popma
I'm also fine with just doing a 2.1 and following up with 2.1.x
releases if issues are found.

Post by Matt Sicker
Unless we have some way to have more than one release on the site,
making it 2.1 might be our best bet.

Post by Remko Popma
Do we need to have a 2.1-beta release, or shall we just do a 2.1
release (and follow up with 2.1.1 etc if issues are found)?
When are we aiming to do this release?
There are still ~10 open Jira tickets targetting 2.1.
Please take a look to see if that list is up to date.

--
Matt Sicker <***@gmail.com>

Remko Popma

2014-09-24 15:59:54 UTC

Permalink

Are there any issues in the list of open 2.1 items
<https://issues.apache.org/jira/issues/?jql=project%20%3D%20LOG4J2%20AND%20fixVersion%20%3D%202.1%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC>
we would want to address for 2.1?

Or should these all be moved to 2.2?

Post by Matt Sicker
That's why I thought calling it a "candidate" release made that
distinction. Plus, Alpha, Beta, Candidate release. Going ABC like that
makes suffixes like Final or Release both come next, though that's not an
issue here.

Post by Matt Sicker
Maybe we can call the "release candidate" a "candidate release", while
the traditional RC is still an RC. So in this case, we do CRs for the
official release (which I believe was how you suggested naming tags).

A beta release is exactly the same as a âregularâ release. Just change
the version in the pom to 2.1-beta1.
As for getting multiple versions on the site, other projects do that.
Maven does it for older versions. It should just be a matter of copying
the template they use.
IMO the only reason to do a beta is if their are new features that we
consider to be not-quite-ready for production. On the other hand, I
consider an RC to be believed to be production ready but requiring
additional feedback. FWIW - I find RCs a bit confusing since we vote on a
ârelease candidateâ with every release.
Ralph
Perhaps we can all take time until this weekend to clean up and polish
before you cut an RC... on Friday?
Gary

Post by Matt Sicker
I know that the work I was doing on log4j-web can wait for 2.2, so no
objections for going ahead with 2.1 from me.

Post by Remko Popma
Gary mentioned that in Commons they have multiple versions on the
site so he suggested using that profile/maven plugin. That said, this may
not be easy and will probably be significant work.
As Gary said, we're all in agreement we can do a 2.1 release, so
there's no need to look into the implications of the beta idea further.
Are there any items we still want to include in this release?
Sent from my iPhone
Matt,
It seems like the consensus is to skip a beta.
You may want to send a [poll] email and get a more formal feel for it.
Gary

Post by Matt Sicker
How would I even be able to release the beta artifacts? The
"release" profile doesn't seem appropriate.

Post by Remko Popma
I'm also fine with just doing a 2.1 and following up with 2.1.x
releases if issues are found.

Post by Matt Sicker
Unless we have some way to have more than one release on the site,
making it 2.1 might be our best bet.

Post by Remko Popma
Do we need to have a 2.1-beta release, or shall we just do a 2.1
release (and follow up with 2.1.1 etc if issues are found)?
When are we aiming to do this release?
There are still ~10 open Jira tickets targetting 2.1.
Please take a look to see if that list is up to date.

Gary Gregory

2014-09-24 16:45:40 UTC

Permalink

For my money, move them all to 2.2.

Gary

Post by Remko Popma
Are there any issues in the list of open 2.1 items
<https://issues.apache.org/jira/issues/?jql=project%20%3D%20LOG4J2%20AND%20fixVersion%20%3D%202.1%20AND%20resolution%20%3D%20Unresolved%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC>
we would want to address for 2.1?
Or should these all be moved to 2.2?

Post by Ralph Goers
When you do a release that release has to be voted on - which makes it a
release âcandidateâ. If it is not approved than the candidate fails, you
fix whatever problems there were and move on to the next candidate. In
short, it is something that is just part of the release process for a
specific release. It doesnât really belong in the artifact id and/or
version. It may need to be represented in the source repository, but that
is difficult to do with Maven.
The notion of Alpha or Beta denotes the expected stability of the release.
Ralph
Confusing! What's wrong with Alpha, Beta and Release? A release
candidate is our internal bits before it gets to A, B, or R.
Gary

Post by Matt Sicker
Maybe we can call the "release candidate" a "candidate release", while
the traditional RC is still an RC. So in this case, we do CRs for the
official release (which I believe was how you suggested naming tags).

A beta release is exactly the same as a âregularâ release. Just change
the version in the pom to 2.1-beta1.
As for getting multiple versions on the site, other projects do that.
Maven does it for older versions. It should just be a matter of copying
the template they use.
IMO the only reason to do a beta is if their are new features that we
consider to be not-quite-ready for production. On the other hand, I
consider an RC to be believed to be production ready but requiring
additional feedback. FWIW - I find RCs a bit confusing since we vote on a
ârelease candidateâ with every release.
Ralph
Perhaps we can all take time until this weekend to clean up and polish
before you cut an RC... on Friday?
Gary

Post by Matt Sicker
I know that the work I was doing on log4j-web can wait for 2.2, so no
objections for going ahead with 2.1 from me.

Post by Remko Popma
Gary mentioned that in Commons they have multiple versions on the
site so he suggested using that profile/maven plugin. That said, this may
not be easy and will probably be significant work.
As Gary said, we're all in agreement we can do a 2.1 release, so
there's no need to look into the implications of the beta idea further.
Are there any items we still want to include in this release?
Sent from my iPhone
Matt,
It seems like the consensus is to skip a beta.
You may want to send a [poll] email and get a more formal feel for it.
Gary

Post by Matt Sicker
How would I even be able to release the beta artifacts? The
"release" profile doesn't seem appropriate.

Post by Remko Popma
I'm also fine with just doing a 2.1 and following up with 2.1.x
releases if issues are found.

Post by Matt Sicker
Unless we have some way to have more than one release on the
site, making it 2.1 might be our best bet.

Post by Remko Popma
Do we need to have a 2.1-beta release, or shall we just do a 2.1
release (and follow up with 2.1.1 etc if issues are found)?
When are we aiming to do this release?
There are still ~10 open Jira tickets targetting 2.1.
Please take a look to see if that list is up to date.

Matt Sicker

2014-09-25 01:31:14 UTC

Permalink

I updated a couple in that list that I assigned to myself. There's an issue
by Gary that looks to be fixed already that he can probably close.

Post by Gary Gregory
For my money, move them all to 2.2.
Gary

Post by Ralph Goers
When you do a release that release has to be voted on - which makes it
a release âcandidateâ. If it is not approved than the candidate fails, you
fix whatever problems there were and move on to the next candidate. In
short, it is something that is just part of the release process for a
specific release. It doesnât really belong in the artifact id and/or
version. It may need to be represented in the source repository, but that
is difficult to do with Maven.
The notion of Alpha or Beta denotes the expected stability of the release.
Ralph
Confusing! What's wrong with Alpha, Beta and Release? A release
candidate is our internal bits before it gets to A, B, or R.
Gary

Post by Matt Sicker
Maybe we can call the "release candidate" a "candidate release", while
the traditional RC is still an RC. So in this case, we do CRs for the
official release (which I believe was how you suggested naming tags).

A beta release is exactly the same as a âregularâ release. Just
change the version in the pom to 2.1-beta1.
As for getting multiple versions on the site, other projects do that.
Maven does it for older versions. It should just be a matter of copying
the template they use.
IMO the only reason to do a beta is if their are new features that we
consider to be not-quite-ready for production. On the other hand, I
consider an RC to be believed to be production ready but requiring
additional feedback. FWIW - I find RCs a bit confusing since we vote on a
ârelease candidateâ with every release.
Ralph
Perhaps we can all take time until this weekend to clean up and
polish before you cut an RC... on Friday?
Gary

Post by Matt Sicker
I know that the work I was doing on log4j-web can wait for 2.2, so
no objections for going ahead with 2.1 from me.

Post by Remko Popma
Gary mentioned that in Commons they have multiple versions on the
site so he suggested using that profile/maven plugin. That said, this may
not be easy and will probably be significant work.
As Gary said, we're all in agreement we can do a 2.1 release, so
there's no need to look into the implications of the beta idea further.
Are there any items we still want to include in this release?
Sent from my iPhone
Matt,
It seems like the consensus is to skip a beta.
You may want to send a [poll] email and get a more formal feel for it.
Gary

Post by Matt Sicker
How would I even be able to release the beta artifacts? The
"release" profile doesn't seem appropriate.

Post by Remko Popma
I'm also fine with just doing a 2.1 and following up with 2.1.x
releases if issues are found.

Post by Matt Sicker
Unless we have some way to have more than one release on the
site, making it 2.1 might be our best bet.

Post by Remko Popma
Do we need to have a 2.1-beta release, or shall we just do a
2.1 release (and follow up with 2.1.1 etc if issues are found)?
When are we aiming to do this release?
There are still ~10 open Jira tickets targetting 2.1.
Please take a look to see if that list is up to date.

--
Matt Sicker <***@gmail.com>