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...
* 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.
* 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?
* 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
Would it make sense to lose the "components" name for SVN in the long
term? Perhaps moving to /m3/trunk or similar?
Cheers,
Brett
--
Brett Porter
[EMAIL PROTECTED]
http://blogs.exist.com/bporter/
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
