[Anthill-pro] Build stamp vs. release version
Yanko, Curtis
curt_yanko at uhc.com
Tue Jun 3 14:39:12 CDT 2008
Wow, I think we've worked at the same place and didn't know it! My last
company did the exact same thing (same numbers even!).
I hear you, especially when you're talking about a shrink wrap app. In
the world of web apps I think it is less of an issue and more of just an
internal name anyway. Still, IT being IT starts at one and counts up and
gets all pedantic about 2.5 vs. 3.0 where as the business sees it as
"just a number, what's the big deal?"
What I do know is that almost everybody NOT in engineering doesn't get
the difference between 2.5 and 3.0 but almost everyone will understand
8.06 after explaining the year month thing just once. Even if that is
just the one internal name and it ships with <insert phony metal
sounding superlative> like Blobdium Enterprise Platinum Server Edition,
them so be it. Everyone knows it due out in June and the next release
isn't until January or whatever.
I just feel like the Linux scheme is a sort of middle ground that I can
get teams to agree on put to rest the debate over Sate/time names and
tags vs. x.y.z.buildnum with both sides thinking they've won!
===
-Curt
W: 860.702.9059
M: 860.881.2050
________________________________
From: anthill-pro-bounces at lists.urbancode.com
[mailto:anthill-pro-bounces at lists.urbancode.com] On Behalf Of Peter
Steele
Sent: Tuesday, June 03, 2008 2:32 PM
To: AnthillPro user and support list.
Subject: RE: [Anthill-pro] Build stamp vs. release version
I've worked at places where Marketing gets to say what the release
version is going to be. One time they changed their mind at the last
minute that our 2.5 release would instead be labeled 3.0. That's why I
have come to prefer an internal name for engineering and an external
name for Marketing. It is a pain though to have to maintain two
strings...
From: anthill-pro-bounces at lists.urbancode.com
[mailto:anthill-pro-bounces at lists.urbancode.com] On Behalf Of Yanko,
Curtis
Sent: Tuesday, June 03, 2008 10:22 AM
To: AnthillPro user and support list.
Subject: RE: [Anthill-pro] Build stamp vs. release version
A classic debate, no doubt. My $.02 is that I hate when we have more
than one name for things. Interestingly I also had a bit of an epiphany
on just this very subject recently.
Let me start with what I don't like about date/time stamps. I feel like
they don't tell me enough, how do you distinguish between two branches
when parallel development is taking place for instance? How can I easily
recognize OM work or bug-fix work?
So if you haven't guessed by now, I'm in favor x.y.z.buildnum style
build numbers. Having said that I do see the value in using SVN
revisions as a buildnumber. But just recently one of our teams was
defending date/time versioning by saying that the business doesn't think
in terms of x.y.z, they tend to think in terms of 'The August Release'
as a for instance.
Then it hit me! Linux style versioning. They recognize their date based
planned releases and version accordingly. So the new Ubuntu that comes
out every May for instance was version 8.04 or May of 2008. The next
release will be 8.10 followed by a 9.04 release the following may. By
mapping our 'x' and 'y' numbers to the calendar, preserve 'z' for om,
bug-fix stuff and through a svn revision in for buildnumber and
everybody should be happy!
If you're doing multiple releases per month you can probably do away
with bug fix and just map that tot eh week or use a Julian week number
in lieu of month.
===
-Curt
W: 860.702.9059
M: 860.881.2050
________________________________
From: anthill-pro-bounces at lists.urbancode.com
[mailto:anthill-pro-bounces at lists.urbancode.com] On Behalf Of Peter
Steele
Sent: Tuesday, June 03, 2008 1:05 PM
To: AnthillPro user and support list.
Subject: [Anthill-pro] Build stamp vs. release version
We're debating whether the build stamp each build gets labeled with
should mirror the release version or be an internally used string only.
For example, some people feel the build stamp should include the time
stamp and SVN revision number, and we obviously wouldn't want to include
that in the official release version. For the official release we want
to use something like x.z.y.<build-number>, similar to what Anthill
uses. But should this official release version necessarily match the
daily build stamp? What do others on this list do as a general rule?
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity to
which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
This e-mail, including attachments, may include confidential and/or
proprietary information, and may be used only by the person or entity to
which it is addressed. If the reader of this e-mail is not the intended
recipient or his or her authorized agent, the reader is hereby notified
that any dissemination, distribution or copying of this e-mail is
prohibited. If you have received this e-mail in error, please notify the
sender by replying to this message and delete this e-mail immediately.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.urbancode.com/pipermail/anthill-pro/attachments/20080603/d65ce81f/attachment.htm
More information about the Anthill-pro
mailing list