Steve: Developing on the Edge - Artifact numbering in JSR 277

Steve: Developing on the Edge

Thoughts on development, Web-services, technology and mountains.

20May
Tue2008

Artifact numbering in JSR 277

Al Blue has a critique of JSR 277's versioning policy, which has 5 digits and a text qualifier. As a result, the syntax for specifying valid ranges is a complete nightmare.

Seems to me that the root cause is that artifact naming/numbering is often driven by marketing "what will we call this product" rather than engineering "this is the 17th build". while marketing is good for naming, once you enter a world with declarative dependencies -OSGI, Ivy, Maven and RPMs all have this- then you need some strict rules on how to name things. JSR 277 seems over complex, and that makes everything downstream suffer.

Posted by steve at 09:38

Comments

new comment thread

Complex Numbersreply to this thread

On 20 May 2008 at 18: 37 Matt Doar commented:

Oh yes. I recommend using a product identifier string and also a project identifier and build label.

Build Label - build type (DEV, QA, REL), branch identifier (maybe shortened), build number (could be an svn revision number if all from one repository). Uniquely identifies every build every time.

Project identifier - major, minor, patch. These values are defined by Engineering and need not be seen by a customer.

Product identifier - whatever Marketing wants, ideally defined in a single places after the build is complete and loaded dynamically by the product when used. Sometimes this looks like a project identifier, but that's just a coincidence.

This approach does need a way to map one or more Product identifiers to a single Project identifier and build label.