release strategies and version management
mcconnell at dpml.net
Tue Nov 2 03:50:10 EST 2004
IMO - mixing up too many things here.
Concern #1: Reconstruction
We need to solidly ground release processes against svn revisions as a
matter of quality assurance. Why - because we want to be able to
rebuild a release at any time and in particular, product users should be
able to rebuild a release at any time without necessarily depending on
For example - let's simulate a release of the current 314 revision of
the runtime platform using currently available tools:
$ svn checkout -r 315 http://paris.dpml.net/svn/metro/main/runtime
$ cd runtime
$ ant -Ddpml.release.signature=315
Total time: 1 minute 53 seconds
Now I can create a file in the current directory named dpml.properties
and add the following line:
dpml.artifact = artifact:meta:dpml/metro/dpml-metro-cli#315
Based on the above I now have a complete set of jar files, blocks, md5,
cli scripts, all signed and ready to run.
$ metro -execute artifact:dpml/tutorial/dpml-tutorial-hello
[INFO ] (tutorial.hello): Hello World!
If I used the -info option I would see that the underlying sub-systems
are in fact linked to the 315 revision. What the above demonstrates is
an almost complete regeneration of a build relative to a revision. I
say almost because the above demo is still running from
dpml-artifact-main SNPASHOT (but that's a minor technical issue related
to the status of development as at 315).
Now technically - what we have above is absolutely brilliant as far a
"cli-app-user" is concerned. Zero worries about the underlying.
Concern #2: Versioning
Version references describe a contract concerning compatibility of a
different deliverable with different aspects of our system. In the
email I posted that kicked-off this thread I proposed version
association against the following two public api groups:
1. component contact
2. facilities contract
Lets' assume that Concorde revision 315 goes through a qa process and
somewhere along the line we get to a point of establish revision 462 as
a release point for a versioned component contract. This would involve
the generation of a release index. The release index becomes a critical
artifact for any developer building compliant components and here - that
association of version X.Y with the release index should be part of that
A second aspect of the release process would be the building of the
facilities SPI release index (not necessarily at the same time). An
important thing here is that a release index for the API should be
grounded against the API release index.
Finally - the release of an implementation locks down against the
facilities SPI release index (and by implication the component API
release index). So in effect we have metro revision 512 implementing
the component api 1.0 and composition spi 1.0.
Concern #3: Branding
Raffi talking about branding generations - and I think it's perfectly ok
to think about the above 512 metro revision as a branded release. Let's
call it 'Concorde' (a metro station in Paris).
> -----Original Message-----
> From: dev-dpml-bounces at lists.ibiblio.org [mailto:dev-dpml-
> bounces at lists.ibiblio.org] On Behalf Of David Leangen
> Sent: 02 November 2004 03:46
> To: dev-dpml at lists.ibiblio.org
> Subject: RE: release strategies and version management
> I'm just wondering what you all think about having a kind of
> or "compromise" approach that does not depend on SVN. If we look at
> from an SoC mindset, we have the internal code management, then we
> publication of the "finished" product. These should be two very
> concerns, IMO.
> What I mean is that upon a major release, whatever the SVN build
> happens to be, we zip up the repository (minus the .svn directories)
> make a "source distribution" available. The number used would be as
> explained in his post.
> I think that this is the simplest approach from the user's
> don't really like the idea of a user's having to look up a table and
> the right revision number, then install SVN just to get the software.
> making too many assumptions about the user and forcing him/her to take
> approach. That's not the "Metro way".
> I think that we should do as much "work" as possible for the user, and
> try to force the user to user our methods. Having a simple
> page with simple major.minor[.build] numbers is simple for the user,
> probably not so difficult for us to implement, either.
> BTW - In reply to Raffael's post:
> > Also, I would not use the version number for "marketing" purposes.
> > If you call something 2.2 just because the version number looks
> > nicer, the information contained in the version number is gone, too.
> I agree. My intended message was simply to point out the importance of
> major.minor[.build] notation from a communications/marketing
> > -----Original Message-----
> > From: Stephen McConnell [mailto:mcconnell at dpml.net]
> > Sent: 2 November 2004 8:50
> > To: dleangen at canada.com; 'Dev'
> > Subject: RE: release strategies and version management
> > > -----Original Message-----
> > > From: dev-dpml-bounces at lists.ibiblio.org [mailto:dev-dpml-
> > > bounces at lists.ibiblio.org] On Behalf Of David Leangen
> > > In that respect, we have to seriously consider the implications of
> > > customer who wants "version 1.2" (or whatever). Can we provide
> > > anytime?
> > In principal - yes.
> > > How is this distributed? If we're only distributing from SVN, can
> > user
> > > somehow execute "svn up -r 1.4"? I don't think so... (I know, it
> > doesn't
> > > change anything from the way it works now... but I'm mentioning
> > now
> > > anyway because it's something that's bugging me...).
> > A build and the complete supporting documentation would be
> > relative to a svn revision number. Given a mapping from revision to
> > version the reverse is true - so for example, a 1.0 corresponding to
> > 309 could be recreated using an svn checkout of that revision
> > by a release build against that codebase.
> > Cheers, Steve.
> dev-dpml mailing list
> dev-dpml at lists.ibiblio.org
More information about the dev-dpml