On 11-Aug-08, at 1:55 AM, Brett Porter wrote:
Hi,
The proposal in the "Versioning" thread brings us to having 3 main
development lines for Maven itself, and that has a couple of
consequences for how we develop that I wanted to explore separately
to see if we're on the same page. These are my thoughts...
I think it's 2. The 2.0.x become bug fixes only and gets reduced to
maintenance mode.
* Merging changes
- All 2.0.x changes are merged to 2.1.x (where still applicable)
- Reasonable effort is made to merge changes from 2.0.x and 2.1.x to
3.0, but if the target code has changed significantly, it is not
required. The presence of integration tests will drive the later re-
implementation of that feature on 3.0, a compatibility layer, or
decision to break compatibility.
Reasonable but the integration tests will play a more critical role
here because the implementations of many moving parts are already
different.
* Integration tests
Integration tests will be the touchstone for verifying behaviour
between the different versions. While perhaps not immediately (see
above), 3.0 must match the integration tests for 2.0.x and 2.1.x,
unless a deliberate, documented decision is made to break
compatibility. This includes both core integration tests and plugin
integration tests as being separately discussed.
* Scope of work
3.0 will have a documented upfront goal and specifications for
behaviour. Primary focus is on architecture rather than feature
growth.
2.1 will allow feature additions, carefully managed for
compatibility with 2.0.x. There's still an expectation they would
work in 3.0 in most cases. This may include some backports from
today's trunk. We should set out a list of objectives up front for
this release also.
Because of multiple feature lines, it becomes even more important to
discuss development plans up front to minimise duplication of effort
and maximise compatibility between versions.
We also need to ensure we don't get back into this situation for
either set of development - so setting a plan for a known release
point and keeping in an always releasable state beyond that.
* Maven Artifact
Should this be folded back into today's trunk given it seems this
would now be replaced by Mercury? Likewise, the MARTIFACT issues
moved back to MNG?
No, why would we fold this back in? Keeping it separate is a good thing.
* Rename JIRA
We will rename 2.1-* to 3.0-* and recreate the 2.1 versions. Both
need to be carefully maintained during development.
* Rename SVN areas
2.0.x branch
2.1.x branch
trunk
Would it make sense to lose the "components" name for SVN in the
long term? Perhaps moving to /m3/trunk or similar?
Not sure if it matters much. The "components" name probably doesn't
make sense but I don't know what to call it.
Cheers,
Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Thanks,
Jason
----------------------------------------------------------
Jason van Zyl
Founder, Apache Maven
jason at sonatype dot com
----------------------------------------------------------
Three people can keep a secret provided two of them are dead.
-- Unknown
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
