Conquistador.
ZynewaveFor quite some time I’ve been bothered about the traditional [major].[minor] version numbering which Podium has used since the very first release. Traditionally this implies that major software updates (major rewrites/redesign) will periodically occur, followed by an increment of the major version number and a reset of the minor version number to 00.
As Podium development has progressed over the years, there has never been a major version update and there probably never will be. All updates are released with few weeks interval and all have incremental feature updates. I’m considering changing the major version number to represent the year of release and the minor version number to count the releases within that year. So the first release in 2009 would be “2009.1” and the next one “2009.2” etc. When reaching 2010 the first release would be “2010.1” etc.
What do you think? Do you have alternative suggestions for a version numbering system?
pavouk100Good idea, it reflects better current state of the matters, and does not invoke false expectations (major version updates).
LiquidProj3ctSorry, but I don’t think that we could see the year 3000 😛 . You could simplify a little erasing the two/three first numbers.
Podium 9.1 instead Podium 2009.1
Podium 12.4 instead Podium 2012.4
Zynewave@LiquidProj3ct wrote:
Sorry, but I don’t think that we could see the year 3000 😛 . You could simplify a little erasing the two/three first numbers.
Podium 9.1 instead Podium 2009.1
Podium 12.4 instead Podium 2012.4
I don’t think that it would be obvious that 9 and 12 represent the year of release, in which case we’re back at the potential confusion that 9 and 12 is major incremental version numbers.
pj geerlings@Zynewave wrote:
@LiquidProj3ct wrote:
Sorry, but I don’t think that we could see the year 3000 😛 . You could simplify a little erasing the two/three first numbers.
Podium 9.1 instead Podium 2009.1
Podium 12.4 instead Podium 2012.4I don’t think that it would be obvious that 9 and 12 represent the year of release, in which case we’re back at the potential confusion that 9 and 12 is major incremental version numbers.
I would agree that it is not immediately obvious
And I do respect your reasoning
But I would like to suggest the 9.xxx versioning for this year is probably adequate for the vast majority of users and a simple explaination “somewhere” should clear up any residual confusion
peace,
pj
Zynewave@pj geerlings wrote:
But I would like to suggest the 9.xxx versioning for this year is probably adequate for the vast majority of users and a simple explaination “somewhere” should clear up any residual confusion
For people that may not know the reasoning behind it, it may appear as an attempt to inflate public opinion of Podium by jumping from 2.09 to 9.01. I fear that it would be the subject of ridicule on forums like kvr.
If the problem is too many digits in “2009.1”, an alternative would be to remove the period in the old version numbers, and present the version as “build 209”, “build 210” etc.?
pj geerlings@Zynewave wrote:
@pj geerlings wrote:
But I would like to suggest the 9.xxx versioning for this year is probably adequate for the vast majority of users and a simple explaination “somewhere” should clear up any residual confusion
For people that may not know the reasoning behind it, it may appear as an attempt to inflate public opinion of Podium by jumping from 2.09 to 9.01. I fear that it would be the subject of ridicule on forums like kvr.
Again, I respect your reasoning ( I have been subjected to ridicule at KVR myself – though for different reasons 😉 )
I would observe that the news annoucement at KVR (and elsewhere) could include a statement outlining the rational behind the versioning change/bump.
@Zynewave wrote:
If the problem is too many digits in “2009.1”, an alternative would be to remove the period in the old version numbers, and present the version as “build 209”, “build 210” etc.?
Could you list the next three releases using this scheme – I’m not sure I get this at all 😕
peace,
pj
Conquistador@Zynewave wrote:
For people that may not know the reasoning behind it, it may appear as an attempt to inflate public opinion of Podium by jumping from 2.09 to 9.01. I fear that it would be the subject of ridicule on forums like kvr.
I agree. It can be easily perceived the wrong way. One slip up like that and it can damage a product for a very long time, especially in such a competitive market. 😐
If the problem is too many digits in “2009.1”, an alternative would be to remove the period in the old version numbers, and present the version as “build 209”, “build 210” etc.?
…”build” sounds like beta to me (the reality could not be further from it of course). I would simply explain on your website that Zynewave does not offer upgrades. Even that explanation is not needed until 2.99…many months or longer from now. Then again to clarify and make things clear to new buyers maybe now is better.
2009.1 seems odd IMO. Removing the period from 2.09 or 2.10 is a whisker away from what we have now.
You could try this if you really must change it…
..updates named after the month they are released…so if you release an update in March simply call it March 09. If the next update follows in June…then Jun 09.
“Zynewave have released a Feb 09 update for Podium”
It is quite differrent and would make me want to find out why the updates are named this way. It creates interest and clearly suggests a massive 3.00 update is somehow not the way things are done here. People just want to know why. I still think the currrent naming convention e.t.c is fine but if you must change it (I can understand your reasons) then that is my suggestion.
Goodnight all! 🙂
H-manI think this is perfectly acceptable for all the reasons mentioned. An announcement of a simple and logical change like this also draws attentioned to Podium (in whatever amount).
You do realise that incrementing the updates by 0.1 limits you to 10 updates per year though….. 😛
Edit: I was refering to the 2009.1 version. 🙂 I like it, all the information is there and little is left to interpretation. Also, given the proposed new licensing system this integrates well.
Is there a committment to how many .x updates/upgrades per year tho? New jaded users will be sceptical of course.
Zynewave@pj geerlings wrote:
@Zynewave wrote:
If the problem is too many digits in “2009.1”, an alternative would be to remove the period in the old version numbers, and present the version as “build 209”, “build 210” etc.?
Could you list the next three releases using this scheme – I’m not sure I get this at all 😕
Build 211, Build 212, Build 213. Essentially just continuing the current numbering without the decimal point. But I have already regretted my use of the word “build”. This is often used as an internal counter of developer compilations.
PiginiI would not bother so much about a completely new version numbering.
I think the current one is absolutely ok. It’s incremental, ongoing, in a way versioning was originally meant do be.
What I never understood was, how some ppl expected major changes, going from 1.99 to 2.0. You are giving us all the inbetweens, instead of secretly working for half a year on a bigger stepping, so logically going from 1.99 to 2.0 had to be an incremental step.
If you compare 1.0 to 2.0, you do have a major difference in features, much more than you would usually see in other apps, that inflate the whole versioning scheme just for PR. (Just look at energy-xt, selling a 2.5 version for showing off, based on an August 2008 beta, while a 2.07beta was released in november 2008.)
But what you rightfully could and should do (IMHO) is, let every small feature change do a count on the version clock.
Then you could have 2.09 being followed by 2.30, having each single improvement in the piano roll do a step on the version meter.
Or count a 0.01 step for a bugfix, 0.1 for an added feature or change.
Right now, the version number does not show the amount of improvements.
The numbering scheme itself does not need to be reinvented, only weighted.
Alternatively, if you absolutely want the year in it, call it “Podium 2009” and carry on with the ususal versioning in the about box.
Zynewave@Conquistador wrote:
I would simply explain on your website that Zynewave does not offer upgrades. Even that explanation is not needed until 2.99…many months or longer from now.
But people would still expect a 3.0 release coming out within 1-2 year after a 2.0 release, as is the normal practice. It was your comment on the VIP topic about the purchase page changes, that made me realize that I need to disassociate the version numbering from peoples expectations when they see a x.xx version format.
..updates named after the month they are released…so if you release an update in March simply call it March 09. If the next update follows in June…then Jun 09.
“Zynewave have released a Feb 09 update for Podium”
Some would read that as Feb the 9th. (and not 2009).
Sometimes there are also more than one release within one month, so year+month is not sufficient.
Pigini@Zynewave wrote:
Build 211, Build 212, Build 213. Essentially just continuing the current numbering without the decimal point. But I have already regretted my use of the word “build”. This is often used as an internal counter of developer compilations.
That numbering looks to me as if you scratched the 0. part of an alpha numbering scheme to make it look better.
Zynewave@H-man wrote:
You do realise that incrementing the updates by 0.1 limits you to 10 updates per year though….. 😛
Edit: I was refering to the 2009.1 version. 🙂
I was thinking of going from 2009.9 to 2009.10 around June 😉
But indeed some may interpret the .1 as indicating month. However I think 2009.001 is too many unnecessary zeroes. Hmm 😕
H-manYeah, I still think it’s the best match for the proposed new licensing system tho.
With all respect to Pigini’s idea, I don’t really like the idea of going form 2.09 to 2.35 to 2.416 (?) etc. I get what it means, it just feels strange.
The Podium release/update/upgrade list has never been less than 10 items IIRC.