[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 i
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 .
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:
ma
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 w
artifacts from a staging repo to a deployment repo. Since the maven repo
is only used internally, we don't have to worry about deploying
something that hasn't passed test yet.
-Original Message-
From: Wendy Smoak [mailto:[EMAIL PROTECTED]
Sent: Thursday, October 19, 2006 3:59 PM
To:
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
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 wh
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 ac
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
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
> 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 th
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
invalidate any assurance that the new build w
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 basi
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 wa
I think this is related to build numbers. You'll have 1.0 build
numbers 1001, 1002,... and you vote on the specific build number.
Maven would automatically use the build number in the manifest.
On 10/16/06, Jason Dillon <[EMAIL PROTECTED]> wrote:
Ya... the build would need to use the release num
[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 t
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
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 doin
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/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
META-INF/M
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
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
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
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 requ
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 in
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 ens
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 binar
27 matches
Mail list logo
