Santiago Gala wrote:
I think that if separate components (artifacts) in the different
releases keep separate versioning it would be easier to manage
dependencies.
Yes, obviously.
I understood that was how it was going to be done for
Jetspeed 2.0, but I was obviously wrong, as the versions of the
different artifacts are bumped just after a release.
My understanding (again, obviously wrong) was that a given artifact was
to be bumped only when actually changed.
In this case this would have been a win since, as no jetspeed artifact
needed by bridges has changed, the release would stand even if jetspeed
itself needed some other artifacts updated.
Am I way off base here?
>
> Regards
> Santiago
It has been discussed in the past for both Jetspeed and Bridges (for Bridges I
think I brought this up myself).
For Bridges, I agree we we should investigate how we can change our release
procedures to accommodate this.
But, although its more easy that way to manage dependencies, it requires us to
change the build setup as well.
Right now, for maven-1, the specific version of a bridge is maintained in the
project.properties in the root.
Upgrading one bridge version also means changing the root of the whole project, and thus also requires tagging the whole of the bridges svn tree even when just
one bridge would need to be released.
But allowing independent bridge releases also means that some bridges might be
in a state of flux while another could be ready to be released.
Tagging the whole svn tree for the release of just one updated bridge would then cause a quite confusing situation which I find even less attractive then our
current release procedure.
This can be solved I think as soon as we go to a maven-2 only build setup,
which I'm going to propose very soon anyway, just as we're planning to do for
Jetspeed 2.
For Jetspeed 2 this discussion is quite more complex as usually a new release of Jetspeed 2 adds many new features and improvements effecting many of its
components, including the shared jetspeed-api. In practice, this makes switching to independent releases for each of the Jetspeed-2 components less useful.
And imagine having to vote upon 20+ independent artifacts to be able to release
a new version of the Jetspeed-2...
Not really my idea of fun, the current release procedure is very time consuming
and elaborate enough already.
Nonetheless, for specific situations like minor fixes or independent (component internal) enhancements, it might be useful if a Jetspeed-2 component could be
released independently as well.
But one big issue I'm seeing with going with independent component releases is
how to handle that with JIRA.
Our JIRA setup for managing/marking releases might need to explode then: as you can't version components in JIRA we might be facing splitting up the JIRA
projects in an unmanageable amount of "sub" projects. I think Cocoon project is currently planning to do this for their (many) blocks components, but I'm afraid
this is going to be very confusing and definitely not very helpful for end users.
Not sure about this yet, but if JIRA cannot be configured to handle separate component releases properly, I might want to stick with our current solution after
all.
I'm definitely willing to discuss this further though so feel free to come up
with a proposal for a practical solution :)
Regards,
Ate
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
