13-12-2003 05:02									#1
	Project: Version numbers Support Apolyton, buy GURPS/ Alpha Centauri

We should probably reach some sort of concensus about how to name versions.

I imagine that we need to have a system that allows for stable releases at regular intervals and frekvent updates to unstable releases ment for playtesting.

there are several well known methods to deal with this but i dont want to get in detail right now.
If you have an idea for a system that would work please share it with us.

klaus

	13-12-2003 19:16									#2
	Browse Apolyton AD-FREE

How about just using dates? E.g. today's version would be "03-12-13".

	13-12-2003 19:38									#3
	Tired of ads?

quote: Originally posted by Leland How about just using dates? E.g. today's version would be "03-12-13".

if we are to use dates i would suggest using the DNS serial system, it goes like this:

YYYYMMDDSS

Y = Year
M = Month
D = Date
S = Serial

Example (today): 2003121301

The serial is to make sure that there can be more than one release a day.
The advantage of this approach is that it is possible for a computer to actively decide if one version is newer than another because the newest version will have the higest numerical value e.g. newversionvar >= oldversionvar is true.
The disadvantage of using dates is that it is hard for modmakers to hold on to a stable release and use it as a foundation for their mods if there isnt an easy way to know what versions are stable and what versions are experimental.

Klaus

	13-12-2003 23:55									#4
	Put an end to popups!

Actual I don't like the order but we have to find something with we can live all. To indiacate instabil more stabil and release build we could lable the alpha and beta builds with respectivly 'a' and 'b' for example, maybe also an r for release version:

2003121302b for the second build we did today that is considered more or less stable but not quite finished.

So far think we only made release versions if we take state of the game as we got it, but actual so far we did only beta builds, so far we added only features or fixed bugs, and something like the slic functions aren't finished.

-Martin

	14-12-2003 00:29									#5
	Support Apolyton buy from Amazon

I second the DNS serial system. It would at least prevent confusion about what is the month and what is the day.

During development, this should work well. Usually, the status (alpha, beta, release candidate) will be clarified in the accompanying readme files or release notes.

For a "real" release, I would prefer the usual major.minor convention, starting with 1.2 for us now, and 2.0 when we are going to change something radically. This will give a clear distinction between those and the "under construction" ones.

	14-12-2003 01:03									#6
	Support Apolyton, buy Galactic Civilizations

Seconding Fromafar.

	15-12-2003 02:06									#7
	Support Apolyton, buy Call to Power 2

It is hard to tell ppl to stop being creative when a stable build release starts getting closer.
I suggest that we go with the DNS serial system for unstable builds and when we want to make a stable build we make a fork on the code and call it X.xxRELEASE_CANDIDATE1 and begin maturing that code without adding new features(and bugs) until it is stable enough to be released. At the same time all new stuff dreamed up by our creative community is carried on in the DNS serial system.

I think this suggestion would work but im open for suggestions as there is plenty of ways to skin this cat

Klaus

	15-12-2003 04:17									#8
	Help yourself to an AD-FREE life

We need to set apart fixes, improvements and minor additions from radical changes to the game. Do not mix these two or the entire thing will go wrong. We need a) a patch that will fix all known bugs that are not hard coded and can be fixed with any minor to medium improvements and minor additions (new features) and b) an add-on, expansion pack or new release, what ever can be possible, for radical and major improvements and additions. I hope that is what you have in mind but I better clarify it.

As for the version numbering format I would suggest we go for a classic major-minor + build model, e.g. 1.2 build 001 or 1.2.001 and so on until we have a final release. We define a life cycle that can last for 1-3 months where bugs are entered and fixed or additions and improvements are made. We can set odd build numbers e.g. 001, 003 etc. for additions and improvements to declare experimental builds and even build numbers for fixes only to declare stable builds. Like the Linux kernel release numbering model. When done we release a patch in a binary file. In the meanwhile we release compressed files of the files altered. If more bugs are found after the lyfe cycle ends we begin again with a version 1.3 and build number starting from where we ended with version 1.2 and so on.

But for all these to work we defenetely need a CVS and a Bug Tracking System as the thread posting system I see makes things harder. To be honest I don't know when and if a CVS and a bug tracking system is going to be hosted in the Apolyton server, I might have missed a post about it, but I can possibly have something myself before Christmas...

	15-12-2003 04:23									#9
	Full PM-box? Change here!

DNS serial system looks good. Certainly dates (in version numbers or otherwise) should be in the year/month/day format to avoid confusion.

I don't think it's necessary to include any sort of stability criterion in the version - the ditinction between alpha and beta builds is pretty insignificant, and when we make a release version we should probably give it a majo.minor version number as Fromafar says. We might want to consider refining this further and using major.minor.revision, but I doubt that it would be neccessary.

Last edited by J Bytheway on 15-12-2003 at 04:45

	15-12-2003 05:30									#10
	Help yourself to an AD-FREE life

The DNS serial system might give a fast overview of how recent the version is but all these numbers make it more difficult to read than a major.minor.build format which people are more used to it. Besides you get an idea of how recent the build is from the post's date or a date reference next to it or even as a comment within the compressed file. The date is not that important to be refered in the version number. What is more important is an easily and fast readable format as the major.minor.build format is.

	15-12-2003 05:35									#11
	Support Apolyton, buy GURPS/ Alpha Centauri

We can also define the rate at which builds are posted. A good idea could be 1-4 weeks depending the rate at which people alter the code and test these changes.

	15-12-2003 05:53									#12
	Increase the size of your Attachments

Well at the moment there are way too few playtesters to test the enormous productivity Fromafar is exercising

	17-12-2003 06:01									#13
	Get a bigger avatar today!

That could be a problem

Well, in that case we can gather all fixes/changes to the code in a distribution file as we're already doing, name it build 001 and test them all. In the meanwhile the programmers continue to alter the source code and post their changes and make distribution files. This new material will not be tested until all changes originally made in build 001 are fully tested. When that is done we gather all the new material, name them build 002 and start a new test cycle and so on until we reach a level that most to all bugs are fixed and release a patch in binary form (patch 1.2).

A test cycle can last from a week to several weeks depending on the workload. The intermediate changes made between two test cycles can keep their DNS serial system and posted in distribution files alltogether once or twice a week either from kaan or Martin or who ever would like to volunteer. I would recommend though you make the name more readable by adding dashes, underscores or dots between year, month and day and use the YYYY/MM/DD format, i.e. 2003.12.17 or 2003_12_17 or 2003-12-17. Since this will be done once or twice per week there won't be a need to add a serial number as per kaan's suggestion unless of cource there has be done an error with a distridution file, like corrupted or missing files within it, where in that case we can add an R2, R3 etc. for revision 2, 3 etc. respectively next to the date whether the corrective distribution file is posted on the same day or the day after.

Looking forward for your opinion.