On 11 Jan 07, at 6:04 PM 11 Jan 07, Kenney Westerhof wrote:
I totally agree.
On that note I have put the one in that I promised for Ralph, and
there is probably one more that I will attempt. So if anyone knows of
a couple they are up for slot them in there.
I pushed all 2.0.x issues to a version called 2.0.x to be the pool of
unscheduled 2.0.x fixes. So things go to the specific versions from
there. I did the same for 2.1.x and 2.2.x.
So if you have time to fix anything in the next two weeks, say, slot
it into 2.0.6.
I will take another pass through JIRA this weekend.
Jason.
This 'micro release' is a rather big bugfix release.
If you have lots of bugfix (micro) releases, and you stumble across
a bug, it's pretty easy to find if it's solved by looking at the
release notes.
That is, if you update frequently. If you don't, you got lots of
bugfix
releasenotes to check, just as people will have to when deciding to
upgrade to 2.0.5.
So this way it's the users choice/fault/responsibility:
* update often - less work to check if a bug has been fixed
* update rarely - more entries to check, just as it is now (2.0.5:
90 issues)
It's also easier to downgrade if you find a new showstopper, since
you won't
loose as much improvements as you would now.
Brian E. Fox wrote:
I agree with Jason on this. My initial reaction was "Weekly!!!! No
way I
can keep all my developers in synch." Then I realized that just
because a build comes out doesn't mean we have
to take it. As long as the plan is clear about what is fixed then it
isn't a huge problem. I might take 2.0.5 simply because it's been so
long, but after that I would probably wait until some compelling
reason
came along to update or after some period of time to avoid becoming
stale.
With the whole voting, vetting process, I'm not sure weekly will be
manageable, biweekly seems more realistic, but I just don't see that
more frequent releases really hurts anyone. -----Original
Message-----
From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Thursday,
January 11, 2007 1:32 PM
To: Maven Developers List
Subject: Re: calling vote for 2.0.5
On 11 Jan 07, at 1:16 PM 11 Jan 07, Rahul Thakur wrote:
+1 for releasing 2.0.5
+0 for micro releases. I agree with Trygve's comment that too
frequent of these can lead to inconsistent developer environments.
Really the point is to schedule them and make the roadmaps
available so that people can take them if they choose. If I had a
team I probably wouldn't grab a micro release every week, but I
might take one monthly or take one that had a fix in it I needed.
I wouldn't expect people to consume them constantly, I just want
to make the fixes available more frequently in an official form
so people can use them.
Jason.
Cheers,
Rahul
----- Original Message ----- From: "Jason van Zyl" <[EMAIL PROTECTED]>
To: "Maven Developers List" <dev@maven.apache.org>
Sent: Thursday, January 11, 2007 11:20 AM
Subject: calling vote for 2.0.5
Hi,
I want to call a vote for 2.0.5. All the issues that are going
to get done are done. We'll release and move on.
I would like to start building all releases from a standard
machine with the same JDK. I would like to propose the
maven.org machine which is monitored 24/7 running Linux. It
serves as the central repository but can easily handle a few
builds. They can be built from that machine and deployed to
Apache. I think this is far better then each of us building
stuff from our own machines and deploying.
Otherwise everything for 2.0.5 is ready to go.
I will also chop up what's in JIRA into some smaller versions as
I think some micro releases for improvements and smaller
changes is better then waiting 7 months for another release. If
we schedule them out them people can decide whether they want
to upgrade or not. But I know there are several things I would
like to get in and I know that Mike/Ralph would like to get in
MNG-1577 which we can squeeze into a 2.0.6 in a week or two.
These are micro release.
Jason.
-------------------------------------------------------------------
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
