Just for reference there are still a couple of updates I need to complete the JIRA stuff - it's 90% there but some housekeeping is still needed which I hope to have done before the end of the week.
Steve.
Niclas Hedhman wrote:
On Wednesday 09 June 2004 06:51, Farr, Aaron wrote:
In SVN our {ttb} structure is such that the WHOLE Avalon source tree is
under one revision.
This is IMHO definately desirable. I want to be able to build the entire thing with a single command.
If this philosophy where carried to JIRA, then we should have only one JIRA project for all of Avalon. And while SVN shows our whole source tree is one singular project, we have a versioning system under /runtime/versioning which clearly shows this isn't the case.
Sorry, you are missing something. Source Control Versioning has nothing to do with release management (and its versioning). I and Stephen has discussed versioning to end of days, and there are several posts here touching on the subject, and my personal conclusion is that one should not assign semantics to a versioned artifact (as in a property of its name), but instead allow for semantics to be added on top, complete agnostic of artifact version number.
IMHO the following needs to be reconciled: * JIRA projects
I got no strong opinion here. But I do think that a 'users view' is more important than 'artifact view'. Perhaps both can exists, so that users drop issues in one end which they understand, and they are sorted into the sections that are more closely related to development, by the developers.
* SVN layout ( {ttb} structure )
IMO, things are already 'fine'.
If you need to branch, copy whatever you want to /repos/asf/avalon/whatever, in practically whatever structure you care for; the whole of runtime or just the Framework Impl if that makes more sense.
* artifact versioning (which relates to repository structure)
Artifact versioning and Release Management is closely related. IMHO, the artifact should probably be name with the SVN revision number if everything is up-to-date, otherwise tagged with some type of 'inofficial' marker, which means that the artifact can not be reconstructed.
In the Release Management, we would then need tools (Magic, for instance) to tie-in which artifacts goes into a 'distro version', such as Merlin 4.0.
Now perhaps I'm just too far behind on the learning curve for SVN, JIRA, and our own versioning scheme, so if someone else knows the master plan I'd really appreciate some illumination. Otherwise, we need to nail this down and reconcile our internal structure.
Except for; 1. JIRA 2. Release Management I think things are pretty well nailed down.
One word about Avalon Planet...
The idea is that "Discovery" will become a 'Component Publishing System', i.e. server side components, and Avalon Planet is "discovery" running 'somewhere'. The Cornerstone and Facilities are "default content" on the Planet, but anyone should be able to publish components fairly easily, and those components are not part of our avalon/planet/ svn directory.
Cheers
Niclas
--
|---------------------------------------| | Magic by Merlin | | Production by Avalon | | | | http://avalon.apache.org | |---------------------------------------|
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
