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
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
+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
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 is that it
the alternative that I see is if we set a cut-off date for features to
be complete. if all features for 2.1.0 must be completed in 4 weeks
and we leave 4 weeks to stabilize then I don't see the need to give a
definitive list of features for 2.1.0 *now*.
[however as I am not currently an
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
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
+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 is that
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
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 work.
+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
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
+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 a
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
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
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
I
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
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
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
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 version for
friday evening
Maven 1 ? Ohh no, not it !
/friday evening
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
+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
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?
-Original
23 matches
Mail list logo
