sqlobject-discuss

[SQLObject] Releases and versioning.

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

Hi all,

I'm seeking some clarity on the versioning and release mechanism for 
SQLObject.

On visiting the sqlobject.org site, various parts of the site refer to 
the current version as 0.5.2. I.e. the front page has a list of "recent 
releases", in which 0.5.2 is the most recent.

But I know that 0.6 is available, because I checked it out of svn myself 
:-) Or did I?

I thought that 0.6 was the latest version, but on looking at the News 
page on the site, that lists 0.6.1 as the most recent release.

http://www.sqlobject.org/docs/News.html

Also, the SQLObject documentation page is the one for 0.6.1.

http://sqlobject.org/docs/SQLObject.html

But I can't see anywhere on the site or on sourceforge to actually 
download 0.6.1. The most recent release on sourceforge is 0.6.0. (I'm 
uncertain as to whether "SQLObject-0.6-1.noarch.rpm" contains 0.6.0 or 
0.6.1?)

http://sourceforge.net/project/showfiles.php?group_id=74338

So I thought I'd go to the definitive source, the ColorStudy svn 
repository. First, I tried to see if there were any svn tags set

prompt> svn ls svn://colorstudy.com/tags/SQLObject/
svn: URL non-existent in that revision

But I see that the tagging is not used in that repository.

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.

Am I the only one who finds this confusing?

Lastly, I have a suggestion to make: use svn tagging to tag/label a 
release so that it is easy to retrieve.

For example, if the 0.6.1 release had been tagged, then I could check 
out the 0.6.1 release with a command like

svn co svn://colorstudy.com/tags/SQLObject/RELEASE_0_6_1

Or something like that. SVN tagging is a simple and powerful mechanism 
to manage this sort of issue (I think RCS and CVS call it "labelling").

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.

Regards,

Alan.

Re: [SQLObject] Releases and versioning.

[Oleg B. <ph...@ma...>]

On Thu, Dec 09, 2004 at 10:15:42PM +0000, Alan Kennedy wrote:
> uncertain as to whether "SQLObject-0.6-1.noarch.rpm" contains 0.6.0 or 
> 0.6.1?)

   0.6.0.

> So I thought I'd go to the definitive source, the ColorStudy svn 
> repository. First, I tried to see if there were any svn tags set
> 
> prompt> svn ls svn://colorstudy.com/tags/SQLObject/
> svn: URL non-existent in that revision
> 
> But I see that the tagging is not used in that repository.

   We do not tag SQLObject releases.

> 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.

   0.6.0. The "head" is in the trunk.

> Am I the only one who finds this confusing?

   Let's me increase the confusion a bit. There are also branches not
under the "branches/" URL! :)
   Now let's me decrease the confusion a bit. You can browse the entire
repository on the web: http://svn.colorstudy.com/ . There you can find
all software in the repository (not only SQLObject), and all branches.
Do not miss my inheritance branch at
   http://svn.colorstudy.com/home/phd/SQLObject/inheritance/ .

> 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.

   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.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

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.

Re: [SQLObject] Releases and versioning.

[Oleg B. <ph...@ma...>]

On Fri, Dec 10, 2004 at 11:39:25AM +0000, Alan Kennedy wrote:
> AFAIK, svn 
> treats tags and branches identically.

   Subversion, actually, does not have a builtin notion of tags and
branches. Svn operates on trees. But one can name theese trees. The
names are just URIs, so one can name them in whatever way one prefers.
"Tags" and "branches" are just two examples of the naming.

> 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?

   Probably. Ian has not created a strict policy on that beside the
http://svn.colorstudy.com/using-this-repository.txt .

> Hmm, so where can I find/download the 0.6.1 release? Was there a formal 
> release of 0.6.1?

   There was no.

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

   Then use the latest checkout from the trunk. I think it is in a more
or less stable state (now). Run tests. This is the best you can get now.

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.

Re: [SQLObject] Releases and versioning.

[Carlos R. <car...@gm...>]

On Fri, 10 Dec 2004 16:09:00 +0300, Oleg Broytmann <ph...@ma...> wrote:
> On Fri, Dec 10, 2004 at 11:39:25AM +0000, Alan Kennedy wrote:
> > AFAIK, svn
> > treats tags and branches identically.
> 
>    Subversion, actually, does not have a builtin notion of tags and
> branches. Svn operates on trees. But one can name theese trees. The
> names are just URIs, so one can name them in whatever way one prefers.
> "Tags" and "branches" are just two examples of the naming.

The SVN book actually makes this point clear, but nevertheless,  it
strongly suggests the use of the trunk/branches/tags structure. That's
what I have used for my own SVN repository. It did sound strange at
first, but as the project grows it does make a lot of sense.
 
>    Then use the latest checkout from the trunk. I think it is in a more
> or less stable state (now). Run tests. This is the best you can get now.

Having tags to mark intermediate releases would be helpful -- it would
encourage the habit of creating mini-releases more frequently (0.6.1,
0.6.2...). But reorganizing the repository may be a little bit
difficult at this point -- lots of people already have copies pointing
to the current structure. But it can be done, anyway, if there's
enough perceived advantage in doing it. (I think it does :-)

-- 
Carlos Ribeiro
Consultoria em Projetos
blog: http://rascunhosrotos.blogspot.com
blog: http://pythonnotes.blogspot.com
mail: car...@gm...
mail: car...@ya...

Re: [SQLObject] Releases and versioning.

[Max I. <ma...@uc...>]

Carlos Ribeiro wrote:

>>   Then use the latest checkout from the trunk. I think it is in a more
>>or less stable state (now). Run tests. This is the best you can get now.
> 
> 
> Having tags to mark intermediate releases would be helpful -- it would
> encourage the habit of creating mini-releases more frequently (0.6.1,
> 0.6.2...). But reorganizing the repository may be a little bit
> difficult at this point -- lots of people already have copies pointing
> to the current structure. But it can be done, anyway, if there's
> enough perceived advantage in doing it. (I think it does :-)

+1 on this. ;-)

Re: [SQLObject] Releases and versioning.

[Ian B. <ia...@co...>]

Alan Kennedy wrote:
> I'm seeking some clarity on the versioning and release mechanism for 
> SQLObject.
> 
> On visiting the sqlobject.org site, various parts of the site refer to 
> the current version as 0.5.2. I.e. the front page has a list of "recent 
> releases", in which 0.5.2 is the most recent.

Damn.  I made changes to the website, uploaded them, but forgot to 
commit them, then uploaded other incremental changes from another site.

> But I know that 0.6 is available, because I checked it out of svn myself 
> :-) Or did I?
> 
> I thought that 0.6 was the latest version, but on looking at the News 
> page on the site, that lists 0.6.1 as the most recent release.
> 
> http://www.sqlobject.org/docs/News.html

Yeah... I guess that should be called "svn head", which will become 
0.6.1.  But somehow 0.6.2 got in my version of the News.  Huh.

> Also, the SQLObject documentation page is the one for 0.6.1.
> 
> http://sqlobject.org/docs/SQLObject.html

And I reuploaded the docs when I made some fixes (mostly which had 
nothing to do with 0.6.1).

> But I can't see anywhere on the site or on sourceforge to actually 
> download 0.6.1. The most recent release on sourceforge is 0.6.0. (I'm 
> uncertain as to whether "SQLObject-0.6-1.noarch.rpm" contains 0.6.0 or 
> 0.6.1?)
> 
> http://sourceforge.net/project/showfiles.php?group_id=74338
> 
> So I thought I'd go to the definitive source, the ColorStudy svn 
> repository. First, I tried to see if there were any svn tags set
> 
> prompt> svn ls svn://colorstudy.com/tags/SQLObject/
> svn: URL non-existent in that revision
> 
> But I see that the tagging is not used in that repository.

No.  There's no deep intention behind it.  OTOH, tagging vs. branching 
seems like a CVS concept, though maybe still a useful metaphor.  A tag 
is just a branch that we agree not to update.

> 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.

There will be a 0.6.1 branch when that is released.

> Am I the only one who finds this confusing?
> 
> Lastly, I have a suggestion to make: use svn tagging to tag/label a 
> release so that it is easy to retrieve.
> 
> For example, if the 0.6.1 release had been tagged, then I could check 
> out the 0.6.1 release with a command like
> 
> svn co svn://colorstudy.com/tags/SQLObject/RELEASE_0_6_1
> 
> Or something like that. SVN tagging is a simple and powerful mechanism 
> to manage this sort of issue (I think RCS and CVS call it "labelling").
> 
> 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.

Sure, I'm open to suggestions on the subversion layout.  At some point 
I'll probably refactor it some, at the same time that I move to http 
(Apache, instead of the standalone server).

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org

Re: [SQLObject] Releases and versioning.

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

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

[Ian Bicking]
 > No.  There's no deep intention behind it.  OTOH, tagging vs. branching
 > seems like a CVS concept, though maybe still a useful metaphor.  A tag
 > is just a branch that we agree not to update.

and

 > Sure, I'm open to suggestions on the subversion layout.  At some point
 > I'll probably refactor it some, at the same time that I move to http
 > (Apache, instead of the standalone server).

Thanks for the reply Ian.

I think the fact that we're even having a discussion about the merits of 
"branches" vs. "tags" and whether they're useful or not is indicative of 
a problem of confusing legacy terminology.

But, subversion makes it easier to use whatever terminology is 
appropriate to the scenario, so I think it best to avoid this kind of 
semantic confusion and name things for what they explicitly are.

Therefore, I would propose to use a "releases" url to hold releases. 
Then use "branches" for the "traditional" meaning of the term, which is 
to be parallel active development trees, e.g. the "inheritance" branch.

Then getting release 0.5.2 or 0.6.1,  would become

svn co svn://colorstudy.com/releases/SQLObject/RELEASE_0_5_2
svn co svn://colorstudy.com/releases/SQLObject/RELEASE_0_6_1

Checking out a copy of the inheritance branch would become

svn co svn://colorstudy.com/branches/SQLObject/inheritance

Also, it should be possible to restrict permission on the "releases" 
subtree, meaning you could restrict permission to make releases, but 
still allow development activity on other sub-urls.

Just one suggestion.

Cheers,

Alan.