Brett Porter a écrit :
On 28/03/2007, at 7:51 AM, Jason van Zyl wrote:
On 27 Mar 07, at 12:30 PM 27 Mar 07, Emmanuel Venisse wrote:
Hi,
I describe there
(http://docs.codehaus.org/display/SCM/Maven-SCM+Release+Process) the
release process and scm structure I'd want to use after the release
of 1.0.
This is missing the tck module, and the plugin. Also, if we do this, the
providers should have their own JIRA project.
I didn't add all but I thought the same thing for tck, plugin and other
providers with trunk/tags/branches
We should do something similar across the board whatever we decide to
do, but you realize that refactoring would be a severe pain in the
ass. I agree providers in any form should be amenable to patching and
releasing but is this the best way to go?
Yeah, I'm 50/50 on this really. I see the benefit, but I'd rather wait
until we have a need to release a provider on a base API before
splitting it off. In addition, the benefit of this is completely lost if
the providers are tightly coupled to the API - so we might want a couple
of releases to ensure that's not the case.
It also adds some overhead in getting testing working.
I don't think this should add any testing overhead if it is done right...
Can we not release from one structure, are we just limited by some
deficiencies in the release plugin?
We can release from a single structure, just like the plugins do now.
Whether that's the right thing to do is also debatable.
oh yes, we can do it. I thought to separated trunk without enough coffee in my
body ;)
so I'm ok to keep the actual trunk structure.
I'd hold off on this until we get 1.0's out across the board and then
hash it out in relation to everything that does the same thing -
plugins, doxia, scm, wagon... even surefire providers.
- Brett
