Re: [SQLObject] Releases and versioning.

[Alan K. <sql...@xh...>]

Oleg,

Thanks for the informative reply.

[Alan Kennedy]
 >>But I see that the tagging is not used in that repository.

[Oleg Broytmann]
 > We do not tag SQLObject releases.

That's a pity. Tags are such an elegant and clean way to manage releases.

It appears to me that the use of "branches" in the ColorStudy svn repo 
is the same usage as I would expect "tags" to be used for. AFAIK, svn 
treats tags and branches identically. So the ColorStudy repo is using 
"branches" for the purpose that "tags" were intended. I know that 
branches and tags are the same thing under svn (i.e. cheap copies), but 
they are different in people's minds. People expect "branches" to 
contain parallel development code bases, and expect "tags" to contain 
fixed snapshots of a code base.

Might it be better to stick with perceived terminology, i.e. use tags to 
label releases? And reserve branches for parallel development, e.g. 
experimental code bases such as the "inheritance" branch?

[Alan Kennedy]
 >>Then I tried
 >>
 >>prompt>svn ls svn://colorstudy.com/branches/SQLObject/
 >>
 >>Which got the following list
 >>
 >>0.5/
 >>0.6/
 >>
 >>I'm presuming that the latter contains the 0.6 code.
 >>
 >>But which release? 0.6.0? 0.6.1? Or the head revision? It's confusing,
 >>without going through the checkin logs in detail to see which version
 >>is which.

[Oleg Broytmann]
 > 0.6.0. The "head" is in the trunk.

Hmm, so where can I find/download the 0.6.1 release? Was there a formal 
release of 0.6.1? My understanding is that the current HEAD contains 
0.6.1+, i.e. whatever comprised the 0.6.1 release *plus* whatever 
changes/fixes have been made since, and which will eventually become 0.6.2.

[Alan Kennedy]
 >>I like to use fixed versions of software, rather than the "bleeding
 >>edge", straight form the repository: it makes testing, installation
 >>and environment management *so* much easier.

[Oleg Broytmann]
 > Then use 0.5.3. It is much more "fixed" than any other. Ian and I
 > fixed a lot of bugs in the trunk in the would-be 0.6.2, but until
 > 0.6.2 will really be released consider 0.6 as a development version.

If it wasn't for the incompatible API between 0.5 and 0.6, I'd consider it.

Thanks and regards,

Alan.