You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@maven.apache.org by Brett Porter <br...@apache.org> on 2005/10/15 19:36:45 UTC
dev process for 2.0.1/2.1
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)
- whether to mark versions as -alpha, -beta along the way, or only label
releases at those points (for 2.1 only on this)
- ensuring plugins remain compatible with 2.0.
- 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)
- how to manage versioning of plugins in JIRA
Ok, not going to include much content here. I have a few thoughts, but I
was hoping to get a varierty of opinions from devs and potential
contributors about what would work best for them.
Cheers
Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dev process for 2.0.1/2.1
Posted by Kenney Westerhof <ke...@apache.org>.
On Tue, 25 Oct 2005, John Casey wrote:
I'll throw in some more coins here.
> | - having a 2.1 trunk and 2.0.1 branch (or vice versa, or neither)
>
> I'm +1 for 2.1 as trunk, and 2.0.x maintenance branch (with that name,
> and tags for 2.0.1, etc.). I think this makes the most sense, and will
> lead to a stable SCM structure, which might be good to avoid the need
> for constant svn relocates...
+1 too, except maybe just use a 2.0 branch and have the poms indicating
2.0.x-SNAPSHOT.
Some of the things I've learned in the last couple of years, just
summarizing:
Usually when you release something, you tag it. When there
are problems on that release, you create a branch based on that tag,
work some more, and tag that branch as 2.0.(x+1). Leave that branch
there in case there's more trouble later on.
Usually branches of previous versions are only kept open when support
for previously released versions has to be continued. When we release 2.1
for instance, the 2.0 branch can be closed, and 2.1 is tagged (and
optionally/probably branched too in a 2.1 branch).
[On a side note, and probably not withing maven scope: since maven is all
about 'project build best practices', I believe that, next to documenting
'our' views of the project structure
(src/(main|test|whatever)/(java|resources|whatever), and splitting up
projects into modules, we should also gather all best
practices in release management (tagging/branching etc.) and put that on
the site too. Maybe we can set the standard - sure would be nice if
everybody everywhere works using the same standards, so I wouldn't have
to convince people of a better way every time I'm on a new job :))
]
> If '2.0.x' isn't the best name for the maintenance branch of 2.0, then
> another name is fine...I just don't want to constantly rename it to the
> latest 2.0.whatever-we're-working-on. It's confusing, because then 2.0.1
> would be a tag on the 2.0.2 branch...
>
> | - whether to mark versions as -alpha, -beta along the way, or only label
> | releases at those points (for 2.1 only on this)
>
> I think 2.0.1 should be -SNAPSHOT, then released, and on to 2.0.2 if
> necessary.
ack. I think X.Y.Z: X = total rewrite, not compatible with previous
versions, Y = new features, Z = bugfix/maintenance release.
> HOWEVER, for the 2.1 line I think we need to make some distinction about
> the feature completeness of the release. -alpha, -beta, etc. is useful
> here, IMO, since there will be some big new features that will have to
> climb that maturity curve.
Alpha is (as I understand from m2) a technology preview, in no way feature
complete. That doesn't quite apply to 2.1. It's a feature addition. The
new features might not work, but that's typical beta stuff. So maybe
skip the alpha here, and just tag the beta-X, rc-X and final release.
Before a beta is near, just use 2.1-SNAPSHOT (in the pom). After the first
beta is released, we can (beta|rc)-(x+1)-SNAPSHOT until final release.
On the other hand, something big like change the pom format to actually
use attributes, i.e.
<dependency groupId="..." artifactId="..." version="..." scope="test"/>
would be a fundamental feature _change_ (instead of new features) and this
would warrant a -alpha. So I think we need to decide whether to put out
alpha's per 2.Y increment.
> | - ensuring plugins remain compatible with 2.0.
>
> For the 2.0.x releases, this is undoubtedly critical. Perhaps we can
> arrange some sort of CI process which will check this for us? A sort of
> build farm for platform-as-maven-version, instead of OS-level platforms...
Don't the integration tests take care of this?
Btw, some previous releases required recompiles from plugins, but no code
changes. We should have a mechanism to indicate a 'support' release that
doesn't fix any bugs, just uses newer deps (this has been mentioned on
the list before, by Brett IINM). Some mechanism like the pom-updates
maybe (also useful for group-renames like plexus).
> Beyond 2.0.x, though, I think we still need to verify that the
> 2.1-targeted plugins are not poisoning the 2.0 execution. This will be
> done through proper use of <prerequisites/>, but should be checked in CI
> somehow...maybe with a plugin? :)
what else? :)
-- Kenney
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dev process for 2.0.1/2.1
Posted by John Casey <jd...@commonjava.org>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm replying to the top-level of the thread, since I'm not sure where
else to attach my 2 cents. :)
<snip/>
| - having a 2.1 trunk and 2.0.1 branch (or vice versa, or neither)
I'm +1 for 2.1 as trunk, and 2.0.x maintenance branch (with that name,
and tags for 2.0.1, etc.). I think this makes the most sense, and will
lead to a stable SCM structure, which might be good to avoid the need
for constant svn relocates...
If '2.0.x' isn't the best name for the maintenance branch of 2.0, then
another name is fine...I just don't want to constantly rename it to the
latest 2.0.whatever-we're-working-on. It's confusing, because then 2.0.1
would be a tag on the 2.0.2 branch...
| - whether to mark versions as -alpha, -beta along the way, or only label
| releases at those points (for 2.1 only on this)
I think 2.0.1 should be -SNAPSHOT, then released, and on to 2.0.2 if
necessary.
HOWEVER, for the 2.1 line I think we need to make some distinction about
the feature completeness of the release. -alpha, -beta, etc. is useful
here, IMO, since there will be some big new features that will have to
climb that maturity curve.
| - ensuring plugins remain compatible with 2.0.
For the 2.0.x releases, this is undoubtedly critical. Perhaps we can
arrange some sort of CI process which will check this for us? A sort of
build farm for platform-as-maven-version, instead of OS-level platforms...
Beyond 2.0.x, though, I think we still need to verify that the
2.1-targeted plugins are not poisoning the 2.0 execution. This will be
done through proper use of <prerequisites/>, but should be checked in CI
somehow...maybe with a plugin? :)
| - 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)
+1, I think this is a GREAT idea. The mish-mash we have now is confusing
to some users, who tend to think everything in there is on the same
release cycle...and that's ignoring the obvious maintenance issues with
having everything on the same trunk structure...
| - how to manage versioning of plugins in JIRA
I'm not an expert on jira, so I'll have to defer/proxy my vote to those
who are. Hopefully, we could create a project per plugin, and manage
multiple release schedules within a single project...is that possible? I
mean, to support the 2.0 line as well as the 2.1 line...
One thing we may need to address in the plugin realm is factoring of a
single plugin into multiple API-compatibility lines (2.0 and 2.1), along
with a common core API that actually implements the plugin
functionality. This means that if you make a fix for a plugin that
addresses the 2.0-compatible branch, and that fix changes core
functionality, it will be included in the 2.1-compatible line, where
there is appropriate overlap. It's not that significant, but it's
something to keep in mind, IMO.
Sorry for the late reply. I've been chewing on this for awhile now, and
wanted to get my thoughts in order before replying.
Cheers,
john
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFDXk2AK3h2CZwO/4URAgvGAJ0UQFQGc3UYuFHdnhrA+MfatyMySACfQcrh
D+L8MJiB2c5XrmPMc9TZu2o=
=2J0z
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dev process for 2.0.1/2.1
Posted by Fabrizio Giustina <fg...@gmail.com>.
On 10/15/05, Brett Porter <br...@apache.org> wrote:
> Here are some areas to think about:
> - having a 2.1 trunk and 2.0.1 branch (or vice versa, or neither)
Well, I always prefer the Flying Fish technique, isn't that
recommended by maven itself? ;)
http://maven.apache.org/development/branches.html
So, go on with the trunk and create a 2.0 branch only if we are going
to commit to 2.1 something that will break compatibility with the 2.0
release, then merge everything to trunk when appropriate.
fabrizio
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dev process for 2.0.1/2.1
Posted by Trygve Laugstøl <tr...@codehaus.org>.
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: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dev process for 2.0.1/2.1
Posted by John Fallows <jo...@gmail.com>.
On 10/17/05, Kenney Westerhof <ke...@apache.org> wrote:
> On Mon, 17 Oct 2005, [ISO-8859-1] Trygve Laugstøl wrote:
> > Brett Porter wrote:
> > > 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).
I think it'll be pretty clear which version we're currently bugfixing,
since 2.0.x releases aren't going to be very frequent in practice.
Most of the active development will be on the trunk. If we think
there's still going to be a lot of active development on 2.0 (rather
than 2.1), then we could delay the 2.0.x branch until we feel things
have settled down on the 2.0 front.
The <version> element in 2.0.x POM would always contain
2.0.[something]-SNAPSHOT, which would then remove the -SNAPSHOT during
release (when /tags/2.0.[something] is created), and then increment to
2.0.[something + 1]-SNAPSHOT on the 2.0.x branch.
Kind Regards,
John Fallows.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dev process for 2.0.1/2.1
Posted by Kenney Westerhof <ke...@apache.org>.
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.
+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
> > - 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..
-- Kenney
> --
> Trygve
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
--
Kenney Westerhof
http://www.neonics.com
GPG public key: http://www.gods.nl/~forge/kenneyw.key
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dev process for 2.0.1/2.1
Posted by Brett Porter <br...@apache.org>.
Arnaud HERITIER wrote:
>>>>- 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.
>>
>>+1
>
>
> Personally, I'm against alpha, beta ...
> It doesn't help us because managers (in companies) don't want to allow their teams to use a library/framework/soft in alpha/beta.
> A lot of projects (httpd, tomcat, ...) doesn't use them anymore.
> The third release number isn't a bug fix but a build increment.
> The team vote to define if a build has the quality of a release or not.
>
We don't have that problem now - we have a stable release. And I don't
want people using alpha quality software in production because then we
have to do a greater amount of support.
For the dev process I agree with you though - we just do releases as we
go and label a certain rev# as 2.1 alpha/beta/milestone, etc, then hit
the final 2.1 when its all sorted out.
- Brett
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
RE: dev process for 2.0.1/2.1
Posted by Arnaud HERITIER <ah...@gmail.com>.
>
> > > - 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.
>
> +1
Personally, I'm against alpha, beta ...
It doesn't help us because managers (in companies) don't want to allow their teams to use a library/framework/soft in alpha/beta.
A lot of projects (httpd, tomcat, ...) doesn't use them anymore.
The third release number isn't a bug fix but a build increment.
The team vote to define if a build has the quality of a release or not.
Arnaud
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dev process for 2.0.1/2.1
Posted by Jason van Zyl <ja...@maven.org>.
On Mon, 2005-10-17 at 10:37 +0200, 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.
+1
> > - 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.
+1
> > - ensuring plugins remain compatible with 2.0.
> > - 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.
+1
> > - 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.
+1
Sorry for responding so late but I created an issue so that I can
capture whatever consensus we reach regarding our own dev process:
http://jira.codehaus.org/browse/MNG-1305
> --
> Trygve
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>
--
jvz.
Jason van Zyl
jason at maven.org
http://maven.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dev process for 2.0.1/2.1
Posted by Trygve Laugstøl <tr...@codehaus.org>.
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.
> - 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.
> - ensuring plugins remain compatible with 2.0.
> - 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.
> - 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.
--
Trygve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org
Re: dev process for 2.0.1/2.1
Posted by John Fallows <jo...@gmail.com>.
I'm hoping to get the chance to contribute some development time to
Maven2 in future, so here is my 2c - maybe it only counts for 1c right
now! :-)
On 10/15/05, Brett Porter <br...@apache.org> wrote:
> 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 like the way the subverison devs do this for subversion itself.
They would have a 2.0.x (literally named "2.0.x") branch, keeping the
trunk for 2.1, and then tag 2.0.1, 2.0.2 etc along the way. Later, a
2.1.x branch can be created to use trunk for 2.2, and so on.
What would the rule be for backporting fixes?
> - whether to mark versions as -alpha, -beta along the way, or only label
> releases at those points (for 2.1 only on this)
Do you need to deliver early 2.1 releases so that plugin developers
can try out new APIs and provide feedback before those APIs get locked
down?
> - ensuring plugins remain compatible with 2.0.
When a new feature is added to 2.1 that a plugin would like to use, it
should be able to do so, perhaps by branching their 2.0-compatible
version and updating the minimum m2 version requirement for the new
plugin version?
> - 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)
Segregating the sources like this is a good idea.
> - how to manage versioning of plugins in JIRA
Do they need to be separately versioned JIRA projects so that
milestones can be set accordingly for bug fixes and feature
enhancements? If so, how to do those plugin versions compare with
plugin versions used by Maven-1 plugins? If there is a collision
here, perhaps the new plugins can be called maven2-xxx-plugin in JIRA?
> Ok, not going to include much content here. I have a few thoughts, but I
> was hoping to get a varierty of opinions from devs and potential
> contributors about what would work best for them.
Kind Regards,
John Fallows.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org