Versioning Software: What pattern do you use?

8 views
Skip to first unread message

Ryan Mueller

unread,
Oct 14, 2014, 9:27:45 AM10/14/14
to team-cf...@googlegroups.com
What type of visioning method do you use for your long running projects.
I'm partial to this. http://semver.org/

Brad Wood

unread,
Oct 14, 2014, 11:24:08 AM10/14/14
to team-cf...@googlegroups.com
We've also started using that versioning system at Ortus.  Well, we've used a simple major.minor.patch.build variant for a while, but we've tightened it down with the advent of CommandBox since version numbers need to be consistently parsable and we'd like to stick to the same standars projects like NPM are using.

For instance the bleeding edge build of ColdBox MVC is currently at version 4.0.0-rc+00002
http://integration.staging.ortussolutions.com/artifacts/ortussolutions/coldbox/box.json

Basically, major.minor.patch-preRelease+build

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp 

ColdBox Platform: http://www.coldbox.org 

Sean Corfield

unread,
Oct 14, 2014, 12:10:06 PM10/14/14
to team-cf...@googlegroups.com
On Oct 14, 2014, at 8:23 AM, Brad Wood <bdw...@gmail.com> wrote:
We've also started using that versioning system at Ortus.  Well, we've used a simple major.minor.patch.build variant for a while, but we've tightened it down with the advent of CommandBox since version numbers need to be consistently parsable and we'd like to stick to the same standars projects like NPM are using.

Strict SemVer is still quite rare but most projects are "close" to it. I've only followed it loosely with FW/1 but it wouldn't hurt me to be a bit more "standard". For example, I tend to omit .Z if it is zero (which I shouldn't) and I tend to use -alpha1 instead of -alpha.1, but I've generally rev'd X for breaking API changes, Y for backward compatible additions (and bug fixes), and Z for just bug fixes.

In the Clojure world, a lot of projects are still 0.Y.Z even tho' their APIs are fairly stable: there's a sense that 1.0.0 is A Big Deal(tm) and so revving Y tends to indicate API changes. That's why the Clojure language is only up to 1.7.0-alpha2 even after seven years and all of the "official" contrib libraries are still at 0.Y.Z!

For instance the bleeding edge build of ColdBox MVC is currently at version 4.0.0-rc+00002
http://integration.staging.ortussolutions.com/artifacts/ortussolutions/coldbox/box.json

Since build metadata (following the +) isn't considered for version precedence, perhaps 4.0.0-rc.2 would be more appropriate? Or is this just the second build of your first RC?

I agree that as the use of CommandBox increases, following proper SemVer will become much more important in the CFML world.

Sean Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)



signature.asc

Brad Wood

unread,
Oct 14, 2014, 12:15:42 PM10/14/14
to team-cf...@googlegroups.com
Well, Java is ~19 years old and still at version 1.8.  Maybe clojure feels like it would be rude to pass them up :)

It's interesting how "commercial" software with a need to drive licenses or renewals bump X's on a much more regular basis. 

Thanks!

~Brad

ColdBox Platform Evangelist
Ortus Solutions, Corp 

ColdBox Platform: http://www.coldbox.org 


Sean Corfield

unread,
Oct 14, 2014, 12:24:34 PM10/14/14
to team-cf...@googlegroups.com
On Oct 14, 2014, at 9:15 AM, Brad Wood <bdw...@gmail.com> wrote:
Well, Java is ~19 years old and still at version 1.8.  Maybe clojure feels like it would be rude to pass them up :)

Hahaha... good point! Clojure is certainly pretty conservative overall in its pace of change:


It's interesting how "commercial" software with a need to drive licenses or renewals bump X's on a much more regular basis.

True. Adobe ColdFusion certainly doesn't follow SemVer (Railo is closer: it revs X when the loader API changes).
signature.asc
Reply all
Reply to author
Forward
0 new messages