Re: [Torcs-ng-devel] Release number scheme

[Annick et Jean-P. <jpm...@fr...>]

Hi, Mart.

>> I'm not against : it's a really secure way ... even it it needs some more
>> work (fix bugs on release branch, and merge them to trunk and other
>> branches).
> 
> I don't expect many patch releases. But this allows us to make sudden releases 
> if bugs arise. Suppose we have in trunk a feature which still is buggy and 
> then a problem with the ./configure-script comes up. Without a maintainance 
> branch we cannot release it, because trunk still has a lot of bugs. The 
> maintanaince branch allows us to still release a new version with that bug 
> resolved fast.

When I said "I'm not against", I meant : I'm OK ;-) You convinced me.

>> The SVN number is not an end-user concern, and I'm not sure it should
>> appear in Torcs-NG screens. It's important for use, though, and may be
>> should be saved somewhere, if we don't use tags.
> 
> Why not use tags? Copiing is O(1) in subversion. But the svn revision version 
> numbering only applies to dev-versions, so only developers need to know about 
> it. It can be in the opening screen if we want with using keywords, but some 
> things need then to be recompiled after every commit. So maybe applying that 
> number only to the splash screen. If should definenitly not in config.h, 
> because that file is included a lot.

I wanted to say that for eand-users releases, the SVN number and the associated
tag say the same thing. So, no need to talk about the SVN numlber if we have put 
a tag. And reverse. Of course I prefer to use tags.

Do you think we need dev releases ? I mean : do you think tags on SVN are not 
sufficient and that we need to (source or binary) package these dev releases ?
I feel that developpers can well "svn co -r <tag>" and build ...

> With more complicated new features, beta-releases can 
> be usefull, especially if there are users which test beta-releases.

Yes, true.

So, let's say whe develop that way :
- the trunk is the feature / next "minor"/"major" (say 1.4.x) release,
- when time to make a minor/major release (say 1.4.0), create a 1.4.x branch,
- developments for next minor/major (say 1.5.0 or 2.0) release can continue
   on the trunk
- on the 1.4.x branch, work to release the 1.4.0
   * make necessary tests/fixes targetting 1.4.0,
   * if unconfident and need extensive tests/fixes, 1.4.0-beta1
     (but generally not necessary => jump to tag 1.4.0-rc1)
   * on feedback, fix bugs
   * may be iterate with 1.4.0-beta2 / 3 ... (but generally not necessary)
   * when confident, tag 1.4.0-rc1 and publish the release to end-users
   * on feedback, fix bugs
   * may be iterate with 1.4.0-rc2 / 3 ... (but generally not necessary)
   * when totally confident, tag 1.4.0 and publish the final release to end-users
- on the 1.4.x branch, work to maintain release the 1.4
   if bad bugs are discovered on the 1.4.0 : same process as for 1.4.0,
   but for 1.4.1, 1.4.2 ...
- other non release/maintenance branches can only be merged to the trunk
   (never to a release/maintenance branch).

Is this method OK for you all ?

Cheers,

Jean-Philippe.