On 21-6-2011 19:04, Josh Andler wrote:
On Tue, Jun 21, 2011 at 3:27 AM, Bruno Winck<bw@...2632...> wrote:
Hi,
If you retain the year.month scheme I have the impression that keeping the year as 2011 as opposed to 11 is more self explanatory. Many users could just not realize that 11 is the year and stay using 11.03 until 2015. Sure it's longer.
Honestly, if people need the full year in the version number, chances are they let all of their software get out of date and it won't matter to them anyway. If we were to have a sophisticated update system, sure we could be like Microsoft and do "Inkscape 2011" so we could do only one major update a year and they'd just get all the bug fixes quarterly or as needed. However, since we don't have that ability, with 2011.10, the .10 is then automatically ambiguous to that class of user. Something like 11.10 makes sense to those it matters to, and looks like a real version number of software to the common user.
Since it is meant as the year number, what is the advantage of _not_ writing the year in full? I vote for full year number, what comes behind the dot might as well be a, b, c... ('2011a', '2011b', ...)
About month. When will you apply the month number ? when you release ? so it means the release will be nameless until the very last moment and of course what about releasing 2012.01 when you are in december 2011. The benefit of service pack number is that 1 follows 0 whatever occurs.
Yes, month number will be month of release. Internally we are still using the old versioning scheme, so it isn't nameless. We're still working on 0.49 which will be 11.XX, then we will work on 0.50 which will be released as 12.X, an interim bugfix release which will use that month number as post decimal identification, then hopefully 0.51 will be 12.XX, etc.
I think the month number is a valid concern, e.g. for about screen contests. Mentioning the month seems a bit too fine granularity for me (why not mention the day?). I think just numbering them 1, 2, 3, or a, b, c is nicer.
Ciao, Johan (trying to keep it simple)