As I noted before, if the ITs are reasonably under control with a way
for people to make them and submit them then I will cut alphas everyday.
Brian is pretty much done. Is that true Brian on the Archetype front?
And you were supposed to figure out the JIRA workflow and I am
supposed to do the patch submission policy.
After this we just warn people and we can cut releases on a weekly
basis.
I don't think you can reasonably say what can be released when until
people actually start doing some work. Until then we pump out alphas,
my only two requirements were above to have some form of sanity for
people to makes tests for us.
On 31 Aug 07, at 8:58 AM 31 Aug 07, Brett Porter wrote:
Hi,
I'm looking to do a few things towards getting a 2.1 alpha out, and
wanted to look towards getting 2.1 itself a bit nearer. It seems
like we have too many things scheduled at the moment for 2.1, so
here are a few bits I've been looking at and was going to start
running through. Would be great to hear others thoughts.
1) 2.1-alpha-1 issues
I would like to cut this back to just the following and start
working on them:
* current known regressions
* integration test failures
and move the rest to 2.1.x as the 2.1 sorting bucket
Any objections?
2) 2.1 JIRA
This has about 270 issues + a large number currently unreviewed
again for us all to go through. I think it needs to be cut down
dramatically - I'd say ~100 issues should be the target here.
I would map it out as 2.1-alpha-2 thru alpha-4: the highest
priority / most addressable / related issues from 2.1.x and the
current 2.1-alpha-1, + the new features from the wiki. I think this
should be all we plan for 2.1 at this point, and move on to feature-
complete betas then. We'll also include stuff that gets addressed
through 2.0.x of course, and anything else that someone gets an
itch to fix or a patch lands for.
Any objections? If others think this is the right approach, I'm
happy to go through and produce a list of what I think should remain.
3) New features
I believe we should categorise these as: required for 2.1, optional
for 2.1, and the rest as beyond 2.1. I think we should be
particularly conservative to make sure a 2.1 release happens sooner.
IMO, the required are:
* decoupling maven-artifact (under way)
* IT problems
* shared build context (mostly done)
* profile activators (mostly done)
* repository mirroring (generally better ability to define
repositories, even without the artifact resolution changes)
* POM loading and building
* Toolchains
* Embedder
* Plugin packs (depends on POM loading as currently defined)
and the optional are:
* java 5 annotations
* conflict resolvers
* artifact handling / artifact resolution spec
* repository security
* local repo separation
* use StAX
I'm also going over the rest of the wiki stuff to help finish up
the things that still needed putting into the current layout and
have a couple of other comments. I'll get back to that over the
weekend.
In my mind, I'd really like to see a realistic chance of 2.1
getting out this year, and planning to have 2 or 3 point releases
next year, each spending time addressing the key issues people
experience and those that get the most bang for our buck with the
open JIRAs.
Thoughts? Any volunteers? :)
Cheers,
Brett
--
Brett Porter - [EMAIL PROTECTED]
Blog: http://www.devzuz.org/blogs/bporter/
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder and PMC Chair, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
