Fair enough, I misunderstood. :)
Stephen Connolly wrote:
afaik, I did not vote for any option (just a time bounded vote) ;-)
Sent from my iPod
On 3 Sep 2008, at 19:22, John Casey <[EMAIL PROTECTED]> wrote:
The result was:
#1: 6 binding: Mark H., Jason, Brett, Wendy, Dan F., Dan K.
2 non-
afaik, I did not vote for any option (just a time bounded vote) ;-)
Sent from my iPod
On 3 Sep 2008, at 19:22, John Casey <[EMAIL PROTECTED]> wrote:
The result was:
#1: 6 binding: Mark H., Jason, Brett, Wendy, Dan F., Dan K.
2 non-binding: Ralph, Raphael
#2: 2 binding: Brian, Dennis
2
The result was:
#1: 6 binding: Mark H., Jason, Brett, Wendy, Dan F., Dan K.
2 non-binding: Ralph, Raphael
#2: 2 binding: Brian, Dennis
2 non-binding: Mauro, Stephen
If you're following the other thread ("Maven 2.1.0 GA Plan") you'll see
that I've started to formalize the suggestions I
As others have said before, since you John are the one doing most of the
work on this I trust your judgement in choosing the best option.
John Casey wrote:
> IMO, the change in version scheme could be a very positive thing, as it
> emphasizes introducing a feature at a time instead of pushing them
IMO, the change in version scheme could be a very positive thing, as it
emphasizes introducing a feature at a time instead of pushing them all
in and claiming that everything is mostly working with some bugs. I
think this may help us manage the chaos that comes from introducing
these sorts of t
I'm +1 for #1.
Cheers,
Mark
2008/8/29 John Casey <[EMAIL PROTECTED]>:
> Okay,
>
> Let's put it to a vote. We have two options:
>
> 1. Release the current release candidate as milestone 1 of the 2.1.0
> codeline. The version for this release would be 2.1.0-M1.
>
> The advantage of this approach i
+1 for #1
On 29-Aug-08, at 9:02 AM, John Casey wrote:
Okay,
Let's put it to a vote. We have two options:
1. Release the current release candidate as milestone 1 of the 2.1.0
codeline. The version for this release would be 2.1.0-M1.
The advantage of this approach is that it keeps is (relat
Brian E. Fox wrote:
Until I see a definitive list of the Milestones for 2.1, I vote for #2.
I am mostly afraid of going down the rat hole that was the old 2.1 with
forever changing scope. I don't see any problem with calling this 2.1
and putting in the other features into 2.2, what's the problem?
My personal preference is #2
The reasoning behind this is that we'd be introducing yet another
versioning scheme into the mix that we already have. This might be
confusing to our users and as John hinted at might not attract as many
users.
John Casey wrote:
> Okay,
>
> Let's put it to a vote. We
ust 29, 2008 12:02 PM
To: Maven Developers List
Subject: [vote] Version for pending release
Okay,
Let's put it to a vote. We have two options:
1. Release the current release candidate as milestone 1 of the 2.1.0
codeline. The version for this release would be 2.1.0-M1.
The advantage
--Original Message-
From: John Casey [mailto:[EMAIL PROTECTED]
Sent: Friday, August 29, 2008 12:02 PM
To: Maven Developers List
Subject: [vote] Version for pending release
Okay,
Let's put it to a vote. We have two options:
1. Release the current release candidate as milestone 1 of the 2.1.0
+1 to #1 (we can always re-release it as 2.1.0 soon after if that
seems better).
No objection if we go with #2 either.
Concrete opinions:
* We should only be maintaining two 2.x branches (one bugfixes, one
for features), no more. We need to get them all back into compilable/
IT-passing stat
Maven 1 ? Ohh no, not it !
On Fri, Aug 29, 2008 at 6:36 PM, Stephen Connolly <
[EMAIL PROTECTED]> wrote:
> I think m1 is more concrete than a beta, while signalling that it's not
> feature complete
>
> Sent from my iPod
>
>
> On 29 Aug 2008, at 17:32, "Raphaël Piéroni" <[EMAIL PROTECTED
Then my vote is advisory as I'm not on the PMC.
Ralph
John Casey said:
> FWIW, this will be a standard ASF vote...72h. :-)
>
> John Casey wrote:
>> Okay,
>>
>> Let's put it to a vote. We have two options:
>>
>> 1. Release the current release candidate as milestone 1 of the 2.1.0
>> codeline. The
I'm okay with frowny faces... :)
Dan Fabulich wrote:
OK, OK, you're convincing me. I was just about to write up an e-mail
about how we don't have to do it as four codebases: since 2.1.0 would
just be like 2.0.10, we'd EOL 2.0.x immediately upon releasing 2.1.0,
and put all future bugfixes the
yeah, the feature-completeness is why I want to stay away from betas on
this if we go that route. Betas are supposed to be feature-complete with
bugs that are [probably] still in the system...that's not what we have here.
Stephen Connolly wrote:
I think m1 is more concrete than a beta, while si
FWIW, this will be a standard ASF vote...72h. :-)
John Casey wrote:
Okay,
Let's put it to a vote. We have two options:
1. Release the current release candidate as milestone 1 of the 2.1.0
codeline. The version for this release would be 2.1.0-M1.
The advantage of this approach is that it kee
I think m1 is more concrete than a beta, while signalling that it's
not feature complete
Sent from my iPod
On 29 Aug 2008, at 17:32, "Raphaël Piéroni"
<[EMAIL PROTECTED]> wrote:
+0.99 for 1
+0.01 for 2
I really like 2.0.10 to be 2.1.0-M1 but i dislike the name i would
prefer 2.1.0-beta-1
OK, OK, you're convincing me. I was just about to write up an e-mail
about how we don't have to do it as four codebases: since 2.1.0 would just
be like 2.0.10, we'd EOL 2.0.x immediately upon releasing 2.1.0, and put
all future bugfixes there. But that'll require a lot of arguing and
discussi
I don't mind 72hrs... it's just you forgot to specify how long the
vote is open for ;-)
Sent from my iPod
On 29 Aug 2008, at 17:29, John Casey <[EMAIL PROTECTED]> wrote:
We have a good codebase now, that's not going to rot if it takes a
full 72h to decide what to call it. At that point, and
+0.99 for 1
+0.01 for 2
I really like 2.0.10 to be 2.1.0-M1 but i dislike the name i would
prefer 2.1.0-beta-1
I don't have found any document stating which pre x.y.z (with x, y, z
integers) standard maven follows.
Raphaël
2008/8/29, John Casey <[EMAIL PROTECTED]>:
> Okay,
>
> Let's put it to
We have a good codebase now, that's not going to rot if it takes a full
72h to decide what to call it. At that point, and after I spin this
latest RC12 with the two nasty bugs fixed, it should be basically a
formality to vote for the actual release, and we can get this done.
It's not 6 months
+1 for #1
John Casey wrote:
Okay,
Let's put it to a vote. We have two options:
1. Release the current release candidate as milestone 1 of the 2.1.0
codeline. The version for this release would be 2.1.0-M1.
The advantage of this approach is that it keeps is (relatively)
focused on only thre
On Fri, Aug 29, 2008 at 9:02 AM, John Casey <[EMAIL PROTECTED]> wrote:
> Okay,
> Let's put it to a vote. We have two options:
I have a slight preference for #2 since I prefer httpd-style
versioning ("it's just a number").
However, my vote goes to whatever John wants, since he's doing most of
the
I vote that this poll is closed in 48hrs (I only want a decision soon,
I dot care which ;-) )
Sent from my iPod
On 29 Aug 2008, at 17:02, John Casey <[EMAIL PROTECTED]> wrote:
Okay,
Let's put it to a vote. We have two options:
1. Release the current release candidate as milestone 1 of the
+1 for #1
Dan
On Friday 29 August 2008 12:02:12 pm John Casey wrote:
> Okay,
>
> Let's put it to a vote. We have two options:
>
> 1. Release the current release candidate as milestone 1 of the 2.1.0
> codeline. The version for this release would be 2.1.0-M1.
>
> The advantage of this approach
Okay,
Let's put it to a vote. We have two options:
1. Release the current release candidate as milestone 1 of the 2.1.0
codeline. The version for this release would be 2.1.0-M1.
The advantage of this approach is that it keeps is (relatively) focused
on only three simultaneous codebases, not
27 matches
Mail list logo
