I totally agree.
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]
