Create a versioning system for hosted libraries about base2

[GoogleCodeExporter]

Java people with continuous integration systems ("daily build") create with 
each compile a tag in subversion. The 
version-number format is often a.b.c.d, where the d stands for the build, which 
is an ever increasing integer.

I think we also should use tags for that. When creating a tag, you just copy 
the trunk to the tags "folder". 
Instantly, you have a snapshot of the trunk (so there's no optimisation of 
tagging a subfolder of trunk). It's like 
some recursive symbolic link to the head (latest) revision at that time. It 
also never changes. And although it is 
technically possible, its good and common practise to only perform read 
operations on tags. So there's no 
committing on the tags "folder".

About versioning: shouldn't we also allow for sub-releases of some components? 
I think the name of the tag 
should be sortable, so you always see the newest version. Something like 
major.minor.sub? 

The url can then be:
http://base2.googlecode.com/svn/tags/version-1.0.0/src/base2.js

OK, when we come to version 10, we have a sorting problem, but we can sort that 
later ;-)

Original comment by [email protected] on 23 Jul 2007 at 9:49

[GoogleCodeExporter]

So a tag is just a copy of the trunk at a given time? That's pretty dumb. I 
dislike
the name "tag" so if we are just going to do a copy then why not copy to 
"version"
instead of "tag"? I prefer my original:

http://base2.googlecode.com/svn/version/1.0/base2.js
http://base2.googlecode.com/svn/version/1.0/src/base2.js
http://base2.googlecode.com/svn/version/1.1 RC1/base2.js
http://base2.googlecode.com/svn/version/1.1/base2.js

That way the URL is easy to remember.

I don't think we should get into complicated build numbers but we can provide 
access
to the current build:

http://base2.googlecode.com/svn/version/dev/base2.js

We can add subfolders for builds below the /version/dev/ directory if you like.

Original comment by [email protected] on 23 Jul 2007 at 12:46

[GoogleCodeExporter]

Why not "version" instead of "tags"? Because everybody who knows subversion, 
knows tags:
http://svnbook.red-bean.com/nightly/en/svn.branchmerge.tags.html

It's kind of a standard, I'm afraid ;-) Every svn-repository has a trunk, tags 
and a branch.
But I don't care if you want to use version. It's all the same to me.

We indeed don't need complicated build numbers. But I'm not sure if the 
major.minor-scheme is enough. Do we 
increase the minor version, when a component (namespace) is updated (as in: 
DOM.version is increased)?

You talk about a "dev" version. I think /trunk/ is and should stay the dev 
version.

About version control systems: when a subversion-hosted software piece is 
released into the wild, most of the time 
two versions are supported. A stable and a development version (Firefox 2 and 
Firefox 3). Active development is of 
course only performed on the development version. However, 
bugfixes/security-stuff should also be possible on the 
stable version.

Best practice is when a product is released, a branch is created. For example 
at the release of 1.0 of base2 we copy 
/trunk/ to /branch/version1.0/. Active development is performend on /trunk/. 
However, we still can apply bugfixes to 
/branch/version1.0/. This is handy when someone uses base2 in a production 
environment. And we can then "merge" 
the changes from /branch/version1.0/ back into the /trunk/ if we want to. 

In this example, the branches (as in: "a branch in time") /trunk/ and 
/branch/version1.0/ will never merge as branch. 
But you can imagine in a corporate environment two project have to work on the 
same software at the same time. 
However, they have a different release schedule. With branching, this is 
possible. However, we don't need this scenario. 
It's only for your info.

And now back to tags: technically, trunk, branch and tags are just all inodes 
(from UNIX) with a version number. It's 
convention you use trunk for active development. In branch, you can have one or 
more versions that need maintenance 
(we only have a stable version). And tags is used for tagging. In Microsoft's 
Source Safe (may that product burn in hell), 
but probably in other version control systems too, they have labels. That's a 
special marker, to identify a repository 
wide version. The subversion guys didn't want to introduce a a new paradigma, 
so they just used copy for that, and 
defined a convention.

Until so far the lecture. If you need to know more, just ask.

I think you are focussing to much on the "right" URL scheme and should embrace 
subversion conventions.
But it's your show...

Question: do you think we need two branches (stable and development)?

Original comment by [email protected] on 23 Jul 2007 at 3:42

[GoogleCodeExporter]

I'm sure you are right about the svn conventions. :-) However, it is only an 
accident
that we are serving from svn. If we had a better host then I would like to keep 
the
/version/ directory structure. If we later decided to host from S3 then the 
"tags"
prefix would look silly.

Versioning is a tricky issue. I will have to ponder on the other points you 
raise.

Original comment by [email protected] on 23 Jul 2007 at 4:06

[GoogleCodeExporter]

As making copies is "cheap", you could always do both ;)
Ie, copy /trunk to /tags/1.0 and /version/1.0

Original comment by curiousdannii on 25 Jul 2007 at 4:08

[GoogleCodeExporter]

@Dean: I see your point with tags now.

@Danni: I know it's cheap. But there has to be a good reason to do both, 
otherwise we might forget it.

Any thoughts on the "Downloads" tab? Some people will probably rather host the 
code from their own site. And 
also the download-tab is more "visible" to ordinary users, who don't know 
subversion. I've seen, google has a 
python script to upload some files...

Original comment by [email protected] on 25 Jul 2007 at 10:12

[GoogleCodeExporter]

I'm still new to SVN too, but I have been thinking about tags as snapshots. 
I've been
using them to create release packages. That way users can either download the 
release
archive, or go in SVN and grab a copy of a particular release there (or link 
from it
directly). I end up with a structure that looks like this:
svnproject/tags/release_2.0b1 .

For Major (API compatible) releases that can receive bug fixes, and provide 
automatic
updates, I'd say branches are the best way to go. This way, you could have 
something
like svnproject/branches/version_2.0.x/file.js. If you plan to retain API
compatibility for an entire major version, you could do it like this:
svnproject/branches/version_2.x/file.js.

The current mainline maintenance version could be held in the trunk, and then
migrated to and from branches are needed.

Using the above structure you could also have experimental branches, and 
releases
with tags, so you might end up with a lite version, in 
branches/version_lite_2.x/,
and  a tagged release like: tags/release_lite_2.1/ etc.

Anything that can receive automatic updates will require a lot of discipline to 
make
sure that sites do not break if they rely on something that can change. Tags 
cannot
be easily changed (at least not if you use the SVN tools, like tortoise SVN, or
subclipse), since those tools have built in options and commands to deal with 
tags.
Likewise, the tools have built in commands for dealing with branch migration and
merging (thought I honestly haven't used them much yet).

In my opinion, I would not recommend to users that they link files which may 
change,
as that can have seemingly random unforeseen consequences. For example, they 
may hack
around a bug, or use a bug as a feature, that is then fixed later for example, 
or a
new version may introduces unintended bugs, etc.

I would always recommend they link to a specific version in the tags section, 
then
update they're scripts manually when a new version is released. This has a side
effect, that expire headers can be used (not sure if that can be set up in 
Google's
SVN though - maybe a different location?), so that even if multiple sites use 
the
same file, they could all grab the cache copy, and improve the end user 
experience
for all sites using a particular tagged version. Expire headers would be a bad 
idea
on a version that could be updated at any time.

From what I can tell, in SVN you should try to think of each tag folder, the 
trunk
folder, and each branch folder as separate project directories - each a copy of 
the
other, if they are all dealing with the same version of your product. Each 
should be
checked in and out separately, not all at once. So your directory structure
considerations should take place only in the parts after trunk, tags/dir, and
branch/dir, as those root level directories have a great deal of not only 
convention,
but actual implemented features that depend on them (in the SVN tools mentioned 
above).

Original comment by [email protected] on 14 Sep 2007 at 7:47

[GoogleCodeExporter]

Versions are now hosted here:

http://base2.googlecode.com/svn/version/

Original comment by [email protected] on 19 Dec 2007 at 9:22

• Changed state: Fixed