maven-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Progress on support for large projects
Date Wed, 13 May 2009 17:41:41 GMT

On May 13, 2009, at 7:02 AM, Ralph Goers wrote:

> On May 13, 2009, at 12:53 AM, David Jencks wrote:
>> I'm even more mystified and understand how you want to use scm even  
>> less.  One of the basic principles I have for scm is that stuff  
>> shouldn't be duplicated, in the sense that if some artifact is  
>> released at version say, the scm location for that release  
>> can be found in only one, unique, place in the scm tree, such as an  
>> svn tag.
>> Now if I understand what you are proposing, its to have
>> +root(1.2-SNAPSHOT)
>> +A(1.1-SNAPSHOT)
>> +B(1.3-SNAPSHOT)
>> Only B has changed since the last release, which was of root (1.1),  
>> A(1.1) and B(1.2); these are the version in the release tag.
> If B is the only thing that has changed then you would have:
> +root(1.2-SNAPSHOT)
>  +A(1.0)
>  +B(1.3-SNAPSHOT)
> In this case two artifacts would be deployed during the release:
> 1. The library bom pom (which, in this case, is the pom in root) for  
> version 1.2.
> 2. The artifact for B 1.3
> A 1.0 is part of the tag, is built and tested during the build, but  
> is not redeployed to the repository. After the release the scm will  
> contain:
> +root(1.2)
>  +A(1.0)
>  +B(1.3)

Sorry I wasn't more specific last night at 2:00 am :-).  I need more  
scm context to understand.  I'm assuming something like svn with

   +root-1.0 (1.0)
   +root-1.1 (1.1)
   \root-1.2 (1.1)
     +A(???? 1.0? 1.0-SNAPSHOT?? 1.1-SNAPSHOT???)

I have several assumptions about releasing stuff...

- development will continue after the release
- therefore the version in "trunk" must be incremented so it's clear  
that snapshots are later than the release
- tags should not contain anything with a snapshot version
- releasing will create a tag of what's been released
- tagging for release creates a copy of an entire svn subtree, not a  
copy with stuff removed.

I see several problems with the svn tree I sketched above:
- there are 3 or 4 copies of A claiming to be version 1.0
- there is no plausible version for trunk/root/A
- in tags, the version of root doesn't match the end of the directory  
name. (there are 2 version 1.1 roots)

I must not be understanding something basic about what you are  
proposing.... I'm probably beating a long-dead horse but could you  
please be even more specific about what scm operations you want to  
have as part of a release and what the scm repo looks like afterwards?

david jencks

> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message