Kenney Westerhof wrote:
On Mon, 17 Oct 2005, [ISO-8859-1] Trygve Laugstøl wrote:
Brett Porter wrote:
Hi,
Now that 2.0 is getting close to rolling out, I wanted to open the floor
for discussion about how we will manage the code going forward. We have
a lot more freedom to do things better now that we're no longer
bootstrapping ourselves.
Here are some areas to think about:
- having a 2.1 trunk and 2.0.1 branch (or vice versa, or neither)
I'd prefer for 2.1 as trunk and 2.0.x as a branch.
Me too. And 2.0.x always being for ONE version only. Perhaps we could
just tag 2.0.1, 2.0.2 etc, and copy that into a branch when bugfixes are
needed. So, when bugs are discovered in 2.0, we copy the 2.0 tag to
2.0.1-SNAPSHOT branch, then work on that. When 2.0.1 is released (and
tagged) we rename the 2.0.1-SNAPSHOT branch to 2.0.2-SNAPSHOT. That way
you can more clearly see what version we're currently bugfixing (instead
of 2.0.x).
- whether to mark versions as -alpha, -beta along the way, or only label
releases at those points (for 2.1 only on this)
I like 2.1-SNAPSHOT over 2.1-alpha-SNAPSHOT.
I think the 2.1-SNAPSHOT is confusing; is that used before or after -alpha
is released? Maybe the ordering should be 2.1-alpha-1-SNAPSHOT,
2.1-alpha-1, 2.1.
Dunno, I see -SNAPSHOT as latest, i.e. trunk.
+1 on -alpha/-beta for 2.x releases and not for 2.x.y releases.
- ensuring plugins remain compatible with 2.0.
.. unless they require features not present in 2.1.
Maybe more importantly:
- ensuring (2.0) plugins remain compatible with 2.1 ?
- segregation of the SVN tree to mirror our release process (some
thoughts in jira on this - essentially making archetypes, plugins and
the sandbox separate to to the main tree)
Separate trunk, tags and branches makes the most sense to me as they
have their own lifecycle.
Just so I understand:
archetypes/(branches|tags|trunk)/ (?? doesn't seem this is an important
enough part of m2 as of yet to split off.. but logicially it is).
plugins/(branches|tags|trunk)/
core/(branches|tags|trunk)/
sandbox/ <-- since this is a playground no tagging/branching needed
Yes. A sandbox might be good, if so I'd like to follow the Jakarta
Commons model where you "graduate" once you're release ready.
Besides, I don't see Archetype as a integral part of Maven 2 as it
doesn't have any dependencies on it outside the Archetype plugin :)
- how to manage versioning of plugins in JIRA
Separate projects like with the Maven 1 projects. Seems to have worked
out fine after the initial workload of setting up all the projects.
Is there no way to have sub-projects in jira? Making everything flat make
sit really hard to manage. I would like to see
* maven2
|
|- plugins
|- core
|- archetypes
|- website/doco
in Jira, but I guess this is impossible..
The only thing you can have right now AFAIK are "project groups" like
this [1].
[1]: http://jira.codehaus.org/secure/BrowseProjects.jspa
--
Trygve
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
