Creating a .NET Release Plugin and Snaphot Versioning

[Shane Isbell <sh...@gmail.com>]

I've been fleshing out how to build a release plugin and one of the major
issues that I am encountering is how do snapshot versioning with .NET. The
standard way to do a version for a .NET assembly is to have a
0.0.0.0format, so there is no way to append a "-SNAPSHOT" to the
version, as with
Java. This is a very tricky situation, as we have to infer whether it is a
snapshot based on the version itself. Doing this however, puts on a
constraint that may not work in all circumstances. I have yet to find a good
set of rules for even standard ways of versioning: it may be an intractable
problem.

Getting into specifics, one idea I had was to have any version specified as
say 1.0.*.* ( a double star) within the pom considered a snapshot. This
version would then be resolved to 1.0.0.0 within the assembly. This
constraint does have consequences: a version like 2.0.4 could not be
snapshotted and 2.0.0.0 be never considered a valid release. Clearly, this
double star rule by itself doesn't work. We also would run into the issue
that 2.0.4.23 may or may not be an actual release: it could just be an
intermediate bug fix; but this could be resolved just by not officially
releasing it to a production and/or public repo.

Another idea I considered was to have anything with a zero as the last digit
a snapshot. So a 2.0.4.* would resolve to 2.0.4.0 and be a considered a
snapshot. Under this approach, the build (fix) version is lost and releases
are then required to increment by 1 each time. This doesn't seem to work
either. We could make it some magic number to indicate that it is a
snapshot, but that has its own problems as well.
Alternatively, we could have a version in pom as say 1.0.1.SNAPSHOT,
allowing us to know that it is a snapshot, but then it needs to resolve to
some number within the assembly. Thoughts?

Shane

Re: Creating a .NET Release Plugin and Snaphot Versioning

[Brett Porter <br...@apache.org>]

On 14/12/2006, at 9:58 AM, Dan Fabulich wrote:

> My favorite scheme for this is that every .NET assembly should have a
> <finalName> that's just the project name, so the "foo" project would
> always build a "foo.dll" regardless of what version number it's
> building.  The version number would be embedded in AssemblyVersion
> metadata, and the string version number (including "-SNAPSHOT" as
> appropriate) would appear in FileVersion.

This sounds right to me.

(and while we generally have agreed that the build numbered releases  
is a generally good idea, I think we also agreed that not everyone  
will want it and it can't be mandatory :)

- Brett

RE: Creating a .NET Release Plugin and Snaphot Versioning

[Dan Fabulich <df...@bea.com>]

I think you've read my BEA Maven requirements doc on the matter, but my
view is that the release plugin as we know it needs to go away, in favor
of a scheme in which "releasing" means copying already-built artifacts.

Specifically, the correct fix is to have all builds have a notion of a
"build number" (so if you deploy foo-1.1 and then deploy it again, you
won't auto-replace the original foo-1.1, but get a new build number of
it) which is *not* included in the filename.

A good chunk of this is already coded, but until I get my ICLA approved
by BEA legal, I'm kind-of stuck. :-(

With that said, responding to your remarks more directly:

> -----Original Message-----
> From: Shane Isbell [mailto:shane.isbell@gmail.com]
> Sent: Wednesday, December 13, 2006 2:43 PM
> To: nmaven-dev@incubator.apache.org
> Subject: Creating a .NET Release Plugin and Snaphot Versioning
> 
> I've been fleshing out how to build a release plugin and one of the
major
> issues that I am encountering is how do snapshot versioning with .NET.
The
> standard way to do a version for a .NET assembly is to have a
> 0.0.0.0format, so there is no way to append a "-SNAPSHOT" to the
> version, as with
> Java. This is a very tricky situation, as we have to infer whether it
is a
> snapshot based on the version itself. Doing this however, puts on a
> constraint that may not work in all circumstances. I have yet to find
a
> good
> set of rules for even standard ways of versioning: it may be an
> intractable
> problem.

Microsoft .NET assemblies allow you to specify your version number in
more than one way: in the AssemblyVersion (which is the numeric version
used for .NET binding) and in the FileVersion (which is purely end-user
informative, and may include strings like "alpha" or "-SNAPSHOT").  It
seems natural (to me) that "-SNAPSHOT" would be listed in the
FileVersion, but that -SNAPSHOT dlls would actually have the same
AssemblyVersion as non-SNAPSHOT dlls.

Another related question is what the AssemblyName metadata should be...
normally, AssemblyName is the name of the assembly, e.g. foo.dll's
AssemblyName is "foo", but it's not clear what AssemblyName should be
for foo-1.1-SNAPSHOT.dll.

If AssemblyName itself contains a version number (e.g. the assembly name
is "foo-1.1-SNAPSHOT", then it no longer matters what we put in the
AssemblyVersion metadata (we could set it to 0.0.0.0), because the
AssemblyName is also used for binding and would be more specific than
AssemblyVersion.  I think that'd be crazy, but it's one idea.

My favorite scheme for this is that every .NET assembly should have a
<finalName> that's just the project name, so the "foo" project would
always build a "foo.dll" regardless of what version number it's
building.  The version number would be embedded in AssemblyVersion
metadata, and the string version number (including "-SNAPSHOT" as
appropriate) would appear in FileVersion.

-Dan

PS Meeting with Legal at 4pm.  With any luck, I'll get permission to
sign the ICLA then.
_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.