Closed GoogleCodeExporter closed 9 years ago
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 doek...@gmail.com
on 23 Jul 2007 at 9:49
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 dean.edw...@gmail.com
on 23 Jul 2007 at 12:46
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 doek...@gmail.com
on 23 Jul 2007 at 3:42
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 dean.edw...@gmail.com
on 23 Jul 2007 at 4:06
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
@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 doek...@gmail.com
on 25 Jul 2007 at 10:12
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 Tou...@gmail.com
on 14 Sep 2007 at 7:47
Versions are now hosted here:
http://base2.googlecode.com/svn/version/
Original comment by dean.edw...@gmail.com
on 19 Dec 2007 at 9:22
Original issue reported on code.google.com by
dean.edw...@gmail.com
on 23 Jul 2007 at 9:31