You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@maven.apache.org by Benjamin Bentmann <be...@udo.edu> on 2010/12/10 18:18:07 UTC

Cleanup to SNAPSHOT version handling

Hi,

as part of MNG-4893 [0] an inconsistency in the way a version string is 
treated as a snapshot or release was detected. In short, the issue is 
about what suffix exactly marks a snapshot version.

The current intention is to revise the logic such that the suffix 
"-SNAPSHOT" (note the leading hyphen) and not just "SNAPSHOT" is 
required to denote a snapshot.

This mail is meant as a heads up for users that unintentionally use 
irregular SNAPSHOT versioning and allow them to adjust their builds. If 
changing the builds to use "-SNAPSHOT" isn't possible, we would like to 
hear the technical reasons for this.

Thanks


Benjamin


[0] http://jira.codehaus.org/browse/MNG-4893

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@maven.apache.org
For additional commands, e-mail: users-help@maven.apache.org


Re: Cleanup to SNAPSHOT version handling

Posted by Baptiste MATHUS <ml...@batmat.net>.
+1. I guess it's OSGi related.

Though I don't do that anymore, since we don't do OSGi anymore too, I've
already done that some years ago.
In fact, I guess this was because it was not totally clear that Maven suffix
had to be -SNAPSHOT and not SNAPSHOT only.

At that time, we were trying to have an exact and simpler matching between
osgi versionning and maven one (then using bnd, felix-plugin & so on).

For the record, here's the versionning grammar for OSGi:
version::=major(’.’minor(’.’micro(’.’qualifier)?)?)?
major::=digit+
minor::=digit+
micro::=digit+
qualifier::=(alpha|digit|’_’|’-’)+
digit::=[0..9]
alpha::=[a..zA..Z]

So, we first decided it would be something like 1.2.3 for releases and
1.2.3-SNAPSHOT while being snapshots. But as the OSGi grammar is quite
strict, 1.2.3-SNAPSHOT isn't valid. So we ended up using 1.2.3.SNAPSHOT
which were valid with OSGi and seemed to go partially well with Maven.

After going through different types of problems (with archiva for example:
http://jira.codehaus.org/browse/MRM-837), we reverted to using -SNAPSHOT and
all went fine then.

To sum up, though I might be wrong, I don't think using .SNAPHOT could
really be a requirement for someone. But maybe a doc page is missing
somewhere to help people understand and correctly map their versionning
between maven and OSGi.
I guess the work done & being done in tycho (and m2e) unveiled a lot of
cases in this field. I'm sure sonatype already have a ton of advice or best
practices to handle this mapping as good as possible?

HTH.

Cheers



2010/12/10 David Jencks <da...@yahoo.com>

> I think I've seen some projects, although I don't recall where, that use
> .SNAPSHOT because then you get legal osgi bundle versions in require-bundle
> instructions in the maven-bundle-plugin.  Presumably this could be fixed in
> the maven-bundle-plugin since it already converts -SNAPSHOT to .SNAPSHOT
> when generating the bundle's own osgi version.
>
> david jencks
>
> On Dec 10, 2010, at 9:18 AM, Benjamin Bentmann wrote:
>
> > Hi,
> >
> > as part of MNG-4893 [0] an inconsistency in the way a version string is
> treated as a snapshot or release was detected. In short, the issue is about
> what suffix exactly marks a snapshot version.
> >
> > The current intention is to revise the logic such that the suffix
> "-SNAPSHOT" (note the leading hyphen) and not just "SNAPSHOT" is required to
> denote a snapshot.
> >
> > This mail is meant as a heads up for users that unintentionally use
> irregular SNAPSHOT versioning and allow them to adjust their builds. If
> changing the builds to use "-SNAPSHOT" isn't possible, we would like to hear
> the technical reasons for this.
> >
> > Thanks
> >
> >
> > Benjamin
> >
> >
> > [0] http://jira.codehaus.org/browse/MNG-4893
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> > For additional commands, e-mail: dev-help@maven.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>


-- 
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Cleanup to SNAPSHOT version handling

Posted by David Jencks <da...@yahoo.com>.
I think I've seen some projects, although I don't recall where, that use .SNAPSHOT because then you get legal osgi bundle versions in require-bundle instructions in the maven-bundle-plugin.  Presumably this could be fixed in the maven-bundle-plugin since it already converts -SNAPSHOT to .SNAPSHOT when generating the bundle's own osgi version.

david jencks

On Dec 10, 2010, at 9:18 AM, Benjamin Bentmann wrote:

> Hi,
> 
> as part of MNG-4893 [0] an inconsistency in the way a version string is treated as a snapshot or release was detected. In short, the issue is about what suffix exactly marks a snapshot version.
> 
> The current intention is to revise the logic such that the suffix "-SNAPSHOT" (note the leading hyphen) and not just "SNAPSHOT" is required to denote a snapshot.
> 
> This mail is meant as a heads up for users that unintentionally use irregular SNAPSHOT versioning and allow them to adjust their builds. If changing the builds to use "-SNAPSHOT" isn't possible, we would like to hear the technical reasons for this.
> 
> Thanks
> 
> 
> Benjamin
> 
> 
> [0] http://jira.codehaus.org/browse/MNG-4893
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Cleanup to SNAPSHOT version handling

Posted by Olivier Lamy <ol...@apache.org>.
+1 for me to accept only : *-SNAPSHOT.
Included 1-SNAPSHOT (our parent poms use this forms), 1.0-SNAPSHOT (a
lot of people/company use the a.b qualifier).

IMHO we must emit a warning/deprecation in 3.0.x for version with only
SNAPSHOT (and fail in 3.1.x).



2010/12/28 Benjamin Bentmann <be...@udo.edu>:
> Brett Porter wrote:
>
>> I think the original reason the logic is how it is was because just
>> "SNAPSHOT" (with no leading version) was valid, but that behaviour has long
>> been (unofficially) deprecated.
>
> Given this style of versioning is apparently in use and I personally see
> nothing wrong with having just "SNAPSHOT" to refer to the HEAD of some
> project I suggest we go with the following for Maven 3.0.2:
>
> a) Treat "SNAPSHOT", "*-SNAPSHOT" and the respective expanded/timestamped
> forms as snapshot versions, anything else as release
> b) Emit a model warning if the project version ends with SNAPSHOT but does
> not match the patterns mentioned in a)
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>



-- 
Olivier Lamy
http://twitter.com/olamy
http://www.linkedin.com/in/olamy

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Cleanup to SNAPSHOT version handling

Posted by Brian Fox <br...@infinity.nu>.
--mobile

On Dec 28, 2010, at 6:50 PM, Jason van Zyl <ja...@maven.org> wrote:

>
> On Dec 28, 2010, at 6:06 PM, Benjamin Bentmann wrote:
>
>> Brian E. Fox wrote:
>>
>>> -1 to a, +1 to b
>>
>> Just to be clear, I meant a) AND b), not either or. a) is concerned about the actual version interpretation, b) about guiding the user into the desired direction for future projects.
>>
>> In light of this, I'm not sure what your "-1 to a" means.
>>
>
> Do not allow "SNAPSHOT" alone I believe is what he means.

Right. That's just a mess waiting to happen.



>
>>
>> Benjamin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
> Thanks,
>
> Jason
>
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
>
> A man enjoys his work when he understands the whole and when he
> is responsible for the quality of the whole
>
> -- Christopher Alexander, A Pattern Language
>
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Cleanup to SNAPSHOT version handling

Posted by Jason van Zyl <ja...@maven.org>.
On Dec 28, 2010, at 6:06 PM, Benjamin Bentmann wrote:

> Brian E. Fox wrote:
> 
>> -1 to a, +1 to b
> 
> Just to be clear, I meant a) AND b), not either or. a) is concerned about the actual version interpretation, b) about guiding the user into the desired direction for future projects.
> 
> In light of this, I'm not sure what your "-1 to a" means.
> 

Do not allow "SNAPSHOT" alone I believe is what he means.

> 
> Benjamin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

A man enjoys his work when he understands the whole and when he
is responsible for the quality of the whole

 -- Christopher Alexander, A Pattern Language




Re: Cleanup to SNAPSHOT version handling

Posted by Benjamin Bentmann <be...@udo.edu>.
Brian E. Fox wrote:

> -1 to a, +1 to b

Just to be clear, I meant a) AND b), not either or. a) is concerned 
about the actual version interpretation, b) about guiding the user into 
the desired direction for future projects.

In light of this, I'm not sure what your "-1 to a" means.


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Cleanup to SNAPSHOT version handling

Posted by "Brian E. Fox" <br...@infinity.nu>.
-1 to a, +1 to b

--Brian (mobile)


On Dec 28, 2010, at 1:20 PM, Jason van Zyl <ja...@maven.org> wrote:

> 
> On Dec 28, 2010, at 10:02 AM, Benjamin Bentmann wrote:
> 
>> Brett Porter wrote:
>> 
>>> I think the original reason the logic is how it is was because just "SNAPSHOT" (with no leading version) was valid, but that behaviour has long been (unofficially) deprecated.
>> 
>> Given this style of versioning is apparently in use and I personally see nothing wrong with having just "SNAPSHOT" to refer to the HEAD of some project I suggest we go with the following for Maven 3.0.2:
>> 
>> a) Treat "SNAPSHOT", "*-SNAPSHOT" and the respective expanded/timestamped forms as snapshot versions, anything else as release
>> b) Emit a model warning if the project version ends with SNAPSHOT but does not match the patterns mentioned in a)
>> 
> 
> +1
> 
> I think anything that moves us closer toward the OSGi versioning would be better. I also think being more explicit with the version would be better and accounts for the case where you have multiple branches and you need to identify the tip of each. I don't think we should allow just "SNAPSHOT" anymore as it provides no version context which I think is important. 
> 
> We often see the following:
> 
> x-SNAPSHOT
> x.y-SNAPSHOT
> x.y.z-SNAPSHOT
> 
> Which at least provide some version context, but ultimately I think we should try to move toward:
> 
> http://www.osgi.org/javadoc/r4v42/org/osgi/framework/Version.html
> 
> So I would opt for b) and emit a warning if not in the *-SNAPSHOT form and officially deprecate "SNAPSHOT" and think about moving toward x.y.z.qualifier as a standard. I don't think multiple version schemes are truly helpful.
> 
>> 
>> Benjamin
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>> 
> 
> Thanks,
> 
> Jason
> 
> ----------------------------------------------------------
> Jason van Zyl
> Founder,  Apache Maven
> http://twitter.com/jvanzyl
> ---------------------------------------------------------
> 
> First, the taking in of scattered particulars under one Idea,
> so that everyone understands what is being talked about ... Second,
> the separation of the Idea into parts, by dividing it at the joints,
> as nature directs, not breaking any limb in half as a bad carver might.
> 
>  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)
> 
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Cleanup to SNAPSHOT version handling

Posted by Jason van Zyl <ja...@maven.org>.
On Dec 28, 2010, at 10:02 AM, Benjamin Bentmann wrote:

> Brett Porter wrote:
> 
>> I think the original reason the logic is how it is was because just "SNAPSHOT" (with no leading version) was valid, but that behaviour has long been (unofficially) deprecated.
> 
> Given this style of versioning is apparently in use and I personally see nothing wrong with having just "SNAPSHOT" to refer to the HEAD of some project I suggest we go with the following for Maven 3.0.2:
> 
> a) Treat "SNAPSHOT", "*-SNAPSHOT" and the respective expanded/timestamped forms as snapshot versions, anything else as release
> b) Emit a model warning if the project version ends with SNAPSHOT but does not match the patterns mentioned in a)
> 

+1

I think anything that moves us closer toward the OSGi versioning would be better. I also think being more explicit with the version would be better and accounts for the case where you have multiple branches and you need to identify the tip of each. I don't think we should allow just "SNAPSHOT" anymore as it provides no version context which I think is important. 

We often see the following:

x-SNAPSHOT
x.y-SNAPSHOT
x.y.z-SNAPSHOT

Which at least provide some version context, but ultimately I think we should try to move toward:

http://www.osgi.org/javadoc/r4v42/org/osgi/framework/Version.html

So I would opt for b) and emit a warning if not in the *-SNAPSHOT form and officially deprecate "SNAPSHOT" and think about moving toward x.y.z.qualifier as a standard. I don't think multiple version schemes are truly helpful.

> 
> Benjamin
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

Thanks,

Jason

----------------------------------------------------------
Jason van Zyl
Founder,  Apache Maven
http://twitter.com/jvanzyl
---------------------------------------------------------

First, the taking in of scattered particulars under one Idea,
so that everyone understands what is being talked about ... Second,
the separation of the Idea into parts, by dividing it at the joints,
as nature directs, not breaking any limb in half as a bad carver might.

  -- Plato, Phaedrus (Notes on the Synthesis of Form by C. Alexander)




Re: Cleanup to SNAPSHOT version handling

Posted by Benjamin Bentmann <be...@udo.edu>.
Brett Porter wrote:

> I think the original reason the logic is how it is was because just "SNAPSHOT" (with no leading version) was valid, but that behaviour has long been (unofficially) deprecated.

Given this style of versioning is apparently in use and I personally see 
nothing wrong with having just "SNAPSHOT" to refer to the HEAD of some 
project I suggest we go with the following for Maven 3.0.2:

a) Treat "SNAPSHOT", "*-SNAPSHOT" and the respective 
expanded/timestamped forms as snapshot versions, anything else as release
b) Emit a model warning if the project version ends with SNAPSHOT but 
does not match the patterns mentioned in a)


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Cleanup to SNAPSHOT version handling

Posted by Brett Porter <br...@apache.org>.
On 13/12/2010, at 10:41 PM, Benjamin Bentmann wrote:

> Brett Porter wrote:
> 
>> [...] "SNAPSHOT" (with no leading version) was valid, but that behaviour has long been (unofficially) deprecated.
> 
> Do you have some more pointers for this deprecation handy?


No - that's what I meant by unofficial :) Discouraged is probably more accurate than deprecated.

It was supported in Maven 1: http://maven.apache.org/maven-1.x/using/managing-dependencies.html

But in Maven 2 I believe we've always encouraged the use of x.y-SNAPSHOT instead (e.g.: https://cwiki.apache.org/confluence/display/MAVENOLD/Repository+-+SNAPSHOT+Handling). I don't recall it being officially deprecated / taken out, nor do I recall it ever being stated to work :) 

- Brett

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Cleanup to SNAPSHOT version handling

Posted by Benson Margulies <bi...@gmail.com>.
Or, 1-SNAPSHOT.

Or, DO-NOT-RELEASE-1-SNAPSHOT

On Wed, Dec 15, 2010 at 6:33 PM, Jörg Hohwiller <jo...@j-hohwiller.de> wrote:
> Hi there,
>
> FYI:
>
> I use "SNAPSHOT" as version for internal artifacts (site-configurations with
> checkstyle, etc.) to denote that they will never get released.
> However in such case one typically does not need real "SNAPSHOT" support by
> maven. I could also name the version "notversioned" or "0.0".
>
> Regards
>  Jörg
>
>> If x-SNAPSHOT.release() = x then SNAPSHOT.release()= npe or divide by
>> zero, take your pick :)
>>
>> I always made sure to point out this anti-pattern during all the maven
>> training classes I did.
>>
>> --mobile
>>
>> On Dec 13, 2010, at 6:42 AM, Benjamin Bentmann
>> <be...@udo.edu> wrote:
>>
>>> Brett Porter wrote:
>>>
>>>> [...] "SNAPSHOT" (with no leading version) was valid, but that behaviour has long been (unofficially) deprecated.
>>>
>>> Do you have some more pointers for this deprecation handy?
>>>
>>>
>>> Benjamin
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Cleanup to SNAPSHOT version handling

Posted by Jörg Schaible <jo...@scalaris.com>.
Hi Baptiste,

Baptiste MATHUS wrote:

> 2010/12/16 Jörg Schaible <jo...@scalaris.com>
> 
>> Hi Baptiste,
>>
>> Baptiste MATHUS wrote:
>>
>> > But then how do you handle releases of the referencing projects? A
>> > clean release must never reference any snapshot, I don't see how you do
>> > it.
>>
>> Hmm, Jörg Hohwiller pointed out that *he* does not release those
>> artifacts. So is this a question to my reply in the original thread?
>>
> 
> True, I guess I mixed the Jörgs, sorry ;-).
> The question stays valid though, but it might not be the exact same
> problem as yours.

The company POM defined all versions of plugins and artifacts in management 
sections. If a component/project has to be released, it will set the 
versions of all required SNAPSHOT dependencies in the company POM to the 
final version, release the company pom (e.g. version 200 and setting again 
SNAPSHOT as next version), release the dependencies and the 
component/project using that version of the company POM as parent. Note, the 
dependencyManagement of the company POM can contain all kind of SNAPSHOT 
versions as long as they are not used in the release process. After the 
release and a new deployment of the company POM, all projects that depend on 
the SNAPSHOT of the company POM will use automatically the new released 
stuff (if they depend on it).

- Jörg


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Cleanup to SNAPSHOT version handling

Posted by Baptiste MATHUS <ml...@batmat.net>.
2010/12/16 Jörg Schaible <jo...@scalaris.com>

> Hi Baptiste,
>
> Baptiste MATHUS wrote:
>
> > But then how do you handle releases of the referencing projects? A clean
> > release must never reference any snapshot, I don't see how you do it.
>
> Hmm, Jörg Hohwiller pointed out that *he* does not release those artifacts.
> So is this a question to my reply in the original thread?
>

True, I guess I mixed the Jörgs, sorry ;-).
The question stays valid though, but it might not be the exact same problem
as yours.

Cheers

-- 
Baptiste <Batmat> MATHUS - http://batmat.net
Sauvez un arbre,
Mangez un castor !

Re: Cleanup to SNAPSHOT version handling

Posted by Jörg Schaible <jo...@scalaris.com>.
Hi Baptiste,

Baptiste MATHUS wrote:

> But then how do you handle releases of the referencing projects? A clean
> release must never reference any snapshot, I don't see how you do it.

Hmm, Jörg Hohwiller pointed out that *he* does not release those artifacts. 
So is this a question to my reply in the original thread?

- Jörg



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Cleanup to SNAPSHOT version handling

Posted by Baptiste MATHUS <bm...@batmat.net>.
But then how do you handle releases of the referencing projects? A clean
release must never reference any snapshot, I don't see how you do it.
Le 16 déc. 2010 00:33, "Jörg Hohwiller" <jo...@j-hohwiller.de> a écrit :
> Hi there,
>
> FYI:
>
> I use "SNAPSHOT" as version for internal artifacts (site-configurations
with
> checkstyle, etc.) to denote that they will never get released.
> However in such case one typically does not need real "SNAPSHOT" support
by
> maven. I could also name the version "notversioned" or "0.0".
>
> Regards
> Jörg
>
>> If x-SNAPSHOT.release() = x then SNAPSHOT.release()= npe or divide by
>> zero, take your pick :)
>>
>> I always made sure to point out this anti-pattern during all the maven
>> training classes I did.
>>
>> --mobile
>>
>> On Dec 13, 2010, at 6:42 AM, Benjamin Bentmann
>> <be...@udo.edu> wrote:
>>
>>> Brett Porter wrote:
>>>
>>>> [...] "SNAPSHOT" (with no leading version) was valid, but that
behaviour has long been (unofficially) deprecated.
>>>
>>> Do you have some more pointers for this deprecation handy?
>>>
>>>
>>> Benjamin
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>>> For additional commands, e-mail: dev-help@maven.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

Re: Cleanup to SNAPSHOT version handling

Posted by Jörg Hohwiller <jo...@j-hohwiller.de>.
Hi there,

FYI:

I use "SNAPSHOT" as version for internal artifacts (site-configurations with
checkstyle, etc.) to denote that they will never get released.
However in such case one typically does not need real "SNAPSHOT" support by
maven. I could also name the version "notversioned" or "0.0".

Regards
  Jörg

> If x-SNAPSHOT.release() = x then SNAPSHOT.release()= npe or divide by
> zero, take your pick :)
> 
> I always made sure to point out this anti-pattern during all the maven
> training classes I did.
> 
> --mobile
> 
> On Dec 13, 2010, at 6:42 AM, Benjamin Bentmann
> <be...@udo.edu> wrote:
> 
>> Brett Porter wrote:
>>
>>> [...] "SNAPSHOT" (with no leading version) was valid, but that behaviour has long been (unofficially) deprecated.
>>
>> Do you have some more pointers for this deprecation handy?
>>
>>
>> Benjamin
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
>> For additional commands, e-mail: dev-help@maven.apache.org
>>
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Cleanup to SNAPSHOT version handling

Posted by Brian Fox <br...@infinity.nu>.
If x-SNAPSHOT.release() = x then SNAPSHOT.release()= npe or divide by
zero, take your pick :)

I always made sure to point out this anti-pattern during all the maven
training classes I did.

--mobile

On Dec 13, 2010, at 6:42 AM, Benjamin Bentmann
<be...@udo.edu> wrote:

> Brett Porter wrote:
>
>> [...] "SNAPSHOT" (with no leading version) was valid, but that behaviour has long been (unofficially) deprecated.
>
> Do you have some more pointers for this deprecation handy?
>
>
> Benjamin
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Cleanup to SNAPSHOT version handling

Posted by Benjamin Bentmann <be...@udo.edu>.
Brett Porter wrote:

> [...] "SNAPSHOT" (with no leading version) was valid, but that behaviour has long been (unofficially) deprecated.

Do you have some more pointers for this deprecation handy?


Benjamin

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org


Re: Cleanup to SNAPSHOT version handling

Posted by Brett Porter <br...@apache.org>.
I think the original reason the logic is how it is was because just "SNAPSHOT" (with no leading version) was valid, but that behaviour has long been (unofficially) deprecated.

On 11/12/2010, at 4:18 AM, Benjamin Bentmann wrote:

> Hi,
> 
> as part of MNG-4893 [0] an inconsistency in the way a version string is treated as a snapshot or release was detected. In short, the issue is about what suffix exactly marks a snapshot version.
> 
> The current intention is to revise the logic such that the suffix "-SNAPSHOT" (note the leading hyphen) and not just "SNAPSHOT" is required to denote a snapshot.
> 
> This mail is meant as a heads up for users that unintentionally use irregular SNAPSHOT versioning and allow them to adjust their builds. If changing the builds to use "-SNAPSHOT" isn't possible, we would like to hear the technical reasons for this.
> 
> Thanks
> 
> 
> Benjamin
> 
> 
> [0] http://jira.codehaus.org/browse/MNG-4893
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
> For additional commands, e-mail: dev-help@maven.apache.org
> 

--
Brett Porter
brett@apache.org
http://brettporter.wordpress.com/
http://au.linkedin.com/in/brettporter





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@maven.apache.org
For additional commands, e-mail: dev-help@maven.apache.org