Comment inline
On 10/19/06, Dan Fabulich [EMAIL PROTECTED] wrote:
I'm very glad that people are having this discussion here. I, too, give
my heartfelt +1 to the notion of promoting the build to a release by
simply copying it, but I've argued elsewhere that the way the
maven-release-plugin
Jason van Zyl wrote on Thursday, October 19, 2006 11:14 PM:
I think skipping release numbers is Bad Thing(tm). It would certainly
confuse users if we release Maven 2.0.7 next.
Anything 2.0.4 would be welcome ... hehehe
Technically you could simply use an additional number at the end:
Jörg Schaible [EMAIL PROTECTED] schrieb am 20.10.2006
10:35:18:
Jason van Zyl wrote on Thursday, October 19, 2006 11:14 PM:
I think skipping release numbers is Bad Thing(tm). It would certainly
confuse users if we release Maven 2.0.7 next.
Anything 2.0.4 would be welcome ... hehehe
[EMAIL PROTECTED] wrote on Friday, October 20, 2006 11:22 AM:
Jörg Schaible [EMAIL PROTECTED] schrieb am
20.10.2006
10:35:18:
Jason van Zyl wrote on Thursday, October 19, 2006 11:14 PM:
I think skipping release numbers is Bad Thing(tm). It would
certainly confuse users if we release
The maven release process criticism from Dan Kulp spawned an impromptu
ApacheCon gathering of the minds (Dan Kulp, Wendy Smoak, Jason Van Zyl,
and Myself) to define a better release process for maven.
First off, thanks for that discussion. It was nice to sit down and
really spell out the
On Saturday October 14 2006 9:30 am, Kenney Westerhof wrote:
Hm. This only describes a major release.
I think that branches should be created off tags, and that a developer
should do that, not a release plugin.
The above process looks ok for major releases (with reservations), but
we
I'm very glad that people are having this discussion here. I, too, give
my heartfelt +1 to the notion of promoting the build to a release by
simply copying it, but I've argued elsewhere that the way the
maven-release-plugin works, really the very idea of the way that it
works, is dangerous from a
On 10/19/06, Daniel Kulp [EMAIL PROTECTED] wrote:
The problem is that this is not ALLOWED. The artifacts that were voted
on MUST be the artifacts that are released. You cannot vote on one set
of artifacts, then build a whole new set of artifacts for the release.
In practice, this does
On Thursday October 19 2006 3:58 pm, Wendy Smoak wrote:
On 10/19/06, Daniel Kulp [EMAIL PROTECTED] wrote:
The problem is that this is not ALLOWED. The artifacts that were
voted on MUST be the artifacts that are released. You cannot vote
on one set of artifacts, then build a whole new
On 19 Oct 06, at 3:58 PM 19 Oct 06, Wendy Smoak wrote:
On 10/19/06, Daniel Kulp [EMAIL PROTECTED] wrote:
The problem is that this is not ALLOWED. The artifacts that were
voted
on MUST be the artifacts that are released. You cannot vote on
one set
of artifacts, then build a whole new
and the Apache processes...
On 10/19/06, Daniel Kulp [EMAIL PROTECTED] wrote:
The problem is that this is not ALLOWED. The artifacts that were
voted
on MUST be the artifacts that are released. You cannot vote on one
set
of artifacts, then build a whole new set of artifacts for the release
Joakim Erdfelt [EMAIL PROTECTED] schrieb am 13.10.2006 20:06:51:
===
== LICENSE FILE / HEADER
The LICENSE file is a unique monster in the world of apache.
It will always be Apache v2.0.
Thank you. But please keep
[EMAIL PROTECTED] wrote on Monday, October 16, 2006 9:05 AM:
Joakim Erdfelt [EMAIL PROTECTED] schrieb am 13.10.2006 20:06:51:
==
=
== LICENSE FILE / HEADER
The LICENSE file is a unique monster in the world of
Kenney Westerhof wrote:
[snip - much discussion]
Hm. This only describes a major release.
I think that branches should be created off tags, and that a developer
should
do that, not a release plugin.
The above process looks ok for major releases (with reservations), but
we probably don't
Sent: Sunday, October 15, 2006 11:13 PM
To: Maven Developers List
Subject: Re: Maven and the Apache processes...
Ya... the build would need to use the release numbers for all those
bits, and only use the rc bits for the artifacts.
Else, you'd have to rebuild... but by rebuilding you basically
Developers List
Subject: Re: Maven and the Apache processes...
Ya... the build would need to use the release numbers for all those
bits, and only use the rc bits for the artifacts.
Else, you'd have to rebuild... but by rebuilding you basically
invalidate any assurance that the new build will be the same
Hi,
just one comment: wouldn't it be better if release:accept would copy the
2.0.5-rcX artifacts to 2.0.5 (like in Joakim's proposal) instead of doing
the build again ?
Tom
On 10/14/06, Kenney Westerhof [EMAIL PROTECTED] wrote:
Hi,
Some comments inline.
Joakim Erdfelt wrote:
The maven
On 10/15/06, Tom Huybrechts [EMAIL PROTECTED] wrote:
Hi,
just one comment: wouldn't it be better if release:accept would copy the
2.0.5-rcX artifacts to 2.0.5 (like in Joakim's proposal) instead of doing
the build again ?
Wouldn't all the internal version numbers in things like
Ya... the build would need to use the release numbers for all those
bits, and only use the rc bits for the artifacts.
Else, you'd have to rebuild... but by rebuilding you basically
invalidate any assurance that the new build will be the same as the
rc build which presumably was voted upon.
On 10/12/06, Daniel Kulp [EMAIL PROTECTED] wrote:
2) The release process - I honestly think Maven does this wrong. At
least for incubator projects, we need to do the
tagging/build/signing/etc.. first, then vote on the resulting binaries.
This definitely doesn't seem to be what maven is doing.
Hi,
Some comments inline.
Joakim Erdfelt wrote:
The maven release process criticism from Dan Kulp spawned an impromptu
ApacheCon gathering of the minds (Dan Kulp, Wendy Smoak, Jason Van Zyl,
and Myself) to define a better release process for maven.
We covered the needs of Apache with regards
On 10/12/06, Jason Dillon [EMAIL PROTECTED] wrote:
On Oct 12, 2006, at 8:15 AM, John Casey wrote:
1. I don't think anyone can complain with compliance issues. One
thing I
would say is, we could/should be using a plugin to resolve the
license file
from the url given in the POM, and include
The maven release process criticism from Dan Kulp spawned an impromptu
ApacheCon gathering of the minds (Dan Kulp, Wendy Smoak, Jason Van Zyl,
and Myself) to define a better release process for maven.
We covered the needs of Apache with regards to
* Apache Top Level Poms (and Incubator
I'm delighted to see these issues addressed. A few small comments below.
On 10/13/06, Joakim Erdfelt [EMAIL PROTECTED] wrote:
The maven release process criticism from Dan Kulp spawned an impromptu
ApacheCon gathering of the minds (Dan Kulp, Wendy Smoak, Jason Van Zyl,
and Myself) to define a
Jason and I have had some chats about this, but I thought it might be good
to bring this up to a wider audience...
With more and more Apache projects (specifically incubator projects) using
maven, there are a lot more people that are running into issues related
to the apache requirements
1. I don't think anyone can complain with compliance issues. One thing I
would say is, we could/should be using a plugin to resolve the license file
from the url given in the POM, and include it in the appropriate place. Not
only would this ensure that the license is properly included in the
On Oct 12, 2006, at 8:15 AM, John Casey wrote:
1. I don't think anyone can complain with compliance issues. One
thing I
would say is, we could/should be using a plugin to resolve the
license file
from the url given in the POM, and include it in the appropriate
place. Not
only would this
27 matches
Mail list logo
