This approach fails to make the release candidate available to a wider
community. We need to make release candidate builds available for
download and from maven central repository so early adopters can try
them easily. But we also need to have release candidates clearly marked
as such so more conservative users know what they are. Reputation of a
quality project takes very long time to build but can be lost in a one
or two rushed releases.
--
Regards,
Igor
On 11-12-05 9:17 AM, Stephen Connolly wrote:
Personally, I'd rather burn 3.0.4 and have 3.0.5, 3.0.6, etc
version numbers are cheap...
if anyone asks what happend to 3.0.4, we just say, oh that was not
released, there's a tag of it in svn, but there are no binaries or source
distributions because it failed for some reason.
On 5 December 2011 13:46, Mirko Friedenhagen<mfriedenha...@gmail.com>wrote:
Hello everybody,
I understand the need to distinguish between these attempts. I now
have a local copy of 3.0.4 on my disc (as well as on some others).
Next month forgetful as I am, I will not know anymore which of the
different 3.0.4 copies was the blessed one. Let alone that the tag in
subversion will have nothing to do with the real thing.
On the other hand I do not like having things named 3.0.4-RC1..10 and
when RC10 should be the "good" version then we try to rebuild this
perfectly behaving binary once again just with a different name and
break it again possibly while doing this.
Here at work I try to convince my coworkers to always increase version
numbers while tagging a new version, even if the change is "really
small". A name already taken is burnt IMO. What about introducing a
fourth number (3.0.4.N) without any special semantics. Then we all
could test the 3.0.4.2, would be sure we talk about the same thing
(instead of "the first of the attempts to release 3.0.4, you know, the
one version we had to draw back" which is not the same as "the second
attempt to release 3.0.4, you know, the second version we had to draw
back" ... ;-)). and when the vote passed this version 3.0.4.N would be
"released" by communicating this to the user list and modifying the
link on http://maven.apache.org/
Regards Mirko
--
http://illegalstateexception.blogspot.com/
https://github.com/mfriedenhagen/
https://bitbucket.org/mfriedenhagen/
On Mon, Dec 5, 2011 at 01:44, Brian Fox<bri...@infinity.nu> wrote:
Again I start a release process and produce a "candidate for release"
build with a naming 3.0.4 for 5 days vote.
Something failed, so it has been fixed and I restarted a vote with a
second "candidate for release" called 3.0.4 for 5 days vote.
(retagging etc.... )
What is the difference with producing something called RC1 (build
which will never published) and rebuild after some days the SAME thing
without the RC end naming ?
Sorry but except some marketing naming I don't see any difference in a
technical point of view (everything can be tracked in the scm).
There's a big difference as we found in the past.
Quoting from myself
(http://www.sonatype.com/people/2008/04/quality-is-not-accidental/)
"The normal release process for Maven is to stage a release, email the
dev list and wait for votes or show stopper issues to occur. The norm
for most releases is 72 hours, but with Maven core releases it was
common to let it bake for a week or more. Based on history, I was
positive that the first few attempts wouldn’t make it through, so we
started with a “pre vote” instead of a vote email.
It seemed that each “pre vote” staged release we posted for dev list
testing showed yet another how come no one noticed that? regression.
It became apparent that we needed more than ever to harness the power
of the full community to squash these regressions. Since tossing out
multiple versions all called “2.0.9″ to such a wide audience was
clearly a bad idea, we started appending -RC[x] to distinguish them.
Additionally, we needed to have a set of operating parameters to guide
this broad level of testing, lest we have chaos in the flood of bug
fix requests."
The point is we need to put something out that is a "release" that the
wider user community will consume and provide feedback on. This has in
the past been very effective at surfacing important issues that won't
be found from people on the dev list, but will be found before the ink
is even dry on the official release.
You can see more of the reasoning here:
http://mail-archives.apache.org/mod_mbox/maven-users/200804.mbox/%3c2babbe7d2a66e04db8a66a527d29927e35e...@intrepid.infinity.nu%3E
This has pretty much been standard fare since 2.0.9, and I don't see a
good reason to deviate. On the contrary, wagon changes are
particularly hard to fully test out and having more eyes are better.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@maven.apache.org
For additional commands, e-mail: dev-h...@maven.apache.org
