As I understand the way maven works, having both SNAPSHOT and a date
stamp is wrong.
In fact, having both a build number and SNAPSHOT is wrong.
What SNAPSHOT does on the maven client side is to ask maven to
download a new version of the software each time it's invoked without
the -o (offline) option. So it makes sense to create a 2.0-
SNAPSHOT.jar to represent all of the working versions of the 2.0-in-
process jars that you build. But if you publish a 2.0-b56-SNAPSHOT,
and the next version is 2.0-b57-SNAPSHOT, the user will have to
declare a dependency on the specific version. That is, either 2.0-b56-
SNAPSHOT or 2.0-b57-SNAPSHOT. And there is no point in declaring a
dependency on a specific build number as a SNAPSHOT since it will
never be refreshed.
To effectively use SNAPSHOT, it should simply be 2.0-SNAPSHOT. When
you refresh the repository, you typically publish both 2.0-b57 and
2.0-SNAPSHOT, which are the identical file. When you then publish 2.0-
b58 and 2.0-SNAPSHOT, folks who depend on the 2.0-SNAPSHOT will get
the new file, folks who want specifically 2.0-b57 will never see the
new download, and if folks want the new stuff but nothing beyond it,
they ask for 2.0-b58.
Craig
On Feb 12, 2007, at 5:37 PM, Wonseok Kim wrote:
> That is what is being discussed. Until then, it's a manual process.
> Also,
> SNAPSHOT is not an automated push unless every nightly build pushes
> the update out.
>
> So may be we should use 2 versions of the full-version - one with
> the date, and
> one without. What do you think?
>
> I hope that it become part of automated process soon.
> We have an option to use date both for the two versions like 2.0-
> b35-20070212 and 2.0-SNAPSHOT-20070212. I'm not sure this is
> required. If anyone have better idea, please tell ASAP.
>
> Thanks,
> -Wonseok
>
Craig Russell
Architect, Sun Java Enterprise System
http://java.sun.com/products/jdo
408 276-5638 mailto:Craig.Russell_at_sun.com
P.S. A good JDO? O, Gasp!
- application/pkcs7-signature attachment: smime.p7s