I was checking out svn.roundcube.net and it looks like there isn't a branch that I can checkout/update that'll always give me the latest stable release. Am I missing something, or could a /branches/stable be created that was always the latest stable released version?
Thanks, Jason
Jason wrote:
I was checking out svn.roundcube.net and it looks like there isn't a branch that I can checkout/update that'll always give me the latest stable release. Am I missing something, or could a /branches/stable be created that was always the latest stable released version?
Thanks, Jason
By it's name, SVN can't ever really be considered "stable" until a branch for release is created. The latest branch that I know of was Thomas' branch for the Addressbook. That should technically be stable, except for the addressbook; however, it's still not a production caliber product.
If you ever check out an SVN, you have to understand that it may contain bugs and not work properly. You're checking out untested code. Usually with RC most of the commits are "kosher" and don't impact the stability of it. But if one does, a patch for it is quickly released.
If you always want the latest stable release, just watch the RC
homepage. That box on the right is the latest general stable build.
Right now I think it's still 0.1-beta2. If you follow the Trac at all,
0.1-RC1 is the next milestone (or so I think) which seems to have ticket
numbers dwindling....
~Brett
Jason,
In general, branches aren't intended for "stable" snapshots - they exist as ongoing work areas to manage some parallel development that needs configuration control but cannot impact the baseline. Branches are usually merged back into the baseline when the parallel development is complete. In Subversion, the convention is to create "tags" for snapshots of revisions that have some meaning. If you look in the RoundCube /tags directory, you'll see the latest revision that was considered "stable," i.e. the v0.1-beta2 version.
Jason wrote:
I was checking out svn.roundcube.net and it looks like there isn't a branch that I can checkout/update that'll always give me the latest stable release. Am I missing something, or could a /branches/stable be created that was always the latest stable released version?
Thanks, Jason
Couldn't you have a tag called stable and move that tag with each stable release so that someone who checks it out will always be able to get the latest release tagged as stable without picking a specific version?
(So you'd probably double tag with each stable release. One tag with the version number that is constant and one that is called stable which moves with each stable release.)
Eric Stadtherr wrote:
Jason,
In general, branches aren't intended for "stable" snapshots - they exist as ongoing work areas to manage some parallel development that needs configuration control but cannot impact the baseline. Branches are usually merged back into the baseline when the parallel development is complete. In Subversion, the convention is to create "tags" for snapshots of revisions that have some meaning. If you look in the RoundCube /tags directory, you'll see the latest revision that was considered "stable," i.e. the v0.1-beta2 version.
Jason wrote:
I was checking out svn.roundcube.net and it looks like there isn't a branch that I can checkout/update that'll always give me the latest stable release. Am I missing something, or could a /branches/stable be created that was always the latest stable released version?
Thanks, Jason
Matt,
That's an excellent idea in principle; however, the challenge is coming up with the process to decide what's stable. How bad does a bug have to be to prevent a revision from getting tagged? Who does the evaluation? Who "moves" the tag?
Automated unit tests with some scripts that manipulate the repository are usually the answer to this, but the maintenance of unit tests is usually a non-trivial effort.
The easiest thing to do is just keep a working copy of your own, and make your own decisions as to whether something is stable enough for your environment.
Matt Kaatman wrote:
Couldn't you have a tag called stable and move that tag with each stable release so that someone who checks it out will always be able to get the latest release tagged as stable without picking a specific version?
(So you'd probably double tag with each stable release. One tag with the version number that is constant and one that is called stable which moves with each stable release.)
Eric Stadtherr wrote:
Jason,
In general, branches aren't intended for "stable" snapshots - they exist as ongoing work areas to manage some parallel development that needs configuration control but cannot impact the baseline. Branches are usually merged back into the baseline when the parallel development is complete. In Subversion, the convention is to create "tags" for snapshots of revisions that have some meaning. If you look in the RoundCube /tags directory, you'll see the latest revision that was considered "stable," i.e. the v0.1-beta2 version.
Jason wrote:
I was checking out svn.roundcube.net and it looks like there isn't a branch that I can checkout/update that'll always give me the latest stable release. Am I missing something, or could a /branches/stable be created that was always the latest stable released version?
Thanks, Jason
Hey Eric,
You don't have to release a stable version often, although it is a nice thing to do.
Normally to get to stable you'll freeze new features and have a specified amount of time to squash bugs.
Once the bugs in the tracker are worked out you create a stable release.
If a critical bug is found, you fix it in the stable branch and move the tag.
Matt
Eric Stadtherr wrote:
Matt,
That's an excellent idea in principle; however, the challenge is coming up with the process to decide what's stable. How bad does a bug have to be to prevent a revision from getting tagged? Who does the evaluation? Who "moves" the tag?
Automated unit tests with some scripts that manipulate the repository are usually the answer to this, but the maintenance of unit tests is usually a non-trivial effort.
The easiest thing to do is just keep a working copy of your own, and make your own decisions as to whether something is stable enough for your environment.
Matt Kaatman wrote:
Couldn't you have a tag called stable and move that tag with each stable release so that someone who checks it out will always be able to get the latest release tagged as stable without picking a specific version?
(So you'd probably double tag with each stable release. One tag with the version number that is constant and one that is called stable which moves with each stable release.)
Eric Stadtherr wrote:
Jason,
In general, branches aren't intended for "stable" snapshots - they exist as ongoing work areas to manage some parallel development that needs configuration control but cannot impact the baseline. Branches are usually merged back into the baseline when the parallel development is complete. In Subversion, the convention is to create "tags" for snapshots of revisions that have some meaning. If you look in the RoundCube /tags directory, you'll see the latest revision that was considered "stable," i.e. the v0.1-beta2 version.
Jason wrote:
I was checking out svn.roundcube.net and it looks like there isn't a branch that I can checkout/update that'll always give me the latest stable release. Am I missing something, or could a /branches/stable be created that was always the latest stable released version?
Thanks, Jason
I have to chime in about tagging and branching. From what I am reading on this thread a few of us have different ideas of how this should work.
The way I ran tagging and branching with CVS was to tag the trunk and branches at different times just so I could have named snapshot. The branches were always for releases. They may have just been internal releases, but they represented an isolated branch of development off of the trunk. Experimental work would stay on the trunk while the release branches were carefully monitored with few changes. With SVN tagging and branching are pretty much the same thing. Either way it is a snapshot of the code base.
For the release branches it is best to maintain a list of known issues. This could be placed on the wiki with a list of the releases. As issues arise for a release on a branch they would be added to the list of known issues to warn off anyone who may be considering moving to a newer release.
See this wiki near the bottom as an example.
http://www.jetbrains.net/confluence/display/ReSharper/Nightly+Builds
They are using Jira and we can achieve much the same with Trac. Resolved issues on branches just need the commit comments to include the ticket number in the form of #123 and Trac will link it to the ticket. That will help show users which issues were resolved on a branch.
Perhaps branches will just go to a single decimal point while tags will have two.
branches\release-1.0.0 branches\release-1.1.0 branches\release-1.2.0 branches\release-1.3.0 branches\release-1.5.0
tags\release-1.0.1 tags\release-1.0.12 tags\release-1.0.19 tags\release-1.0.23 tags\release-1.0.59
The as bug fixes are made to the trunk they would be merged the the current release branch and given a tag. Once we have this in place we can have recommended release. And like the Jetbrains example, we can rate the releases on the number of known issues and the severity of the known issues.
From what I am reading it sounds like experimental changes are broken off into branches and perhaps later merged into the trunk. That is contrary to what I typically see on open source and proprietary projects. A branch is generally a way of freezing development so you can stabilize the release by identifying and eliminating the known issues.
I have been frustrated today by past bugs creeping back into my RC installation even though they were apparently fixed a long while back. I have no idea what version to grab from SVN. It seems like as I install a more current version I am just running in circles. For my personal projects I create clearly marked branches.
http://svn.offwhite.net/trac/SmallSharpTools.UrlMapper/browser/branches http://svn.offwhite.net/trac/SmallSharpTools.EmbeddedScripts/browser/branche...
Brennan
On Sun, 14 Jan 2007 21:53:11 -0700, Eric Stadtherr estadtherr@gmail.com wrote:
Matt,
That's an excellent idea in principle; however, the challenge is coming up with the process to decide what's stable. How bad does a bug have to be to prevent a revision from getting tagged? Who does the evaluation? Who "moves" the tag?
Automated unit tests with some scripts that manipulate the repository are usually the answer to this, but the maintenance of unit tests is usually a non-trivial effort.
The easiest thing to do is just keep a working copy of your own, and make your own decisions as to whether something is stable enough for your environment.
Matt Kaatman wrote:
Couldn't you have a tag called stable and move that tag with each stable release so that someone who checks it out will always be able to get the latest release tagged as stable without picking a specific version?
(So you'd probably double tag with each stable release. One tag with the version number that is constant and one that is called stable which moves with each stable release.)
Eric Stadtherr wrote:
Jason,
In general, branches aren't intended for "stable" snapshots - they
exist
as ongoing work areas to manage some parallel development that needs configuration control but cannot impact the baseline. Branches are usually merged back into the baseline when the parallel development is complete. In Subversion, the convention is to create "tags" for snapshots of revisions that have some meaning. If you look in the RoundCube /tags directory, you'll see the latest revision that was considered "stable," i.e. the v0.1-beta2 version.
Jason wrote:
I was checking out svn.roundcube.net and it looks like there isn't a branch that I can checkout/update that'll always give me the latest stable release. Am I missing something, or could a /branches/stable be created that was always the latest stable released version?
Thanks, Jason
-- *Eric Stadtherr* estadtherr@gmail.com mailto:estadtherr@gmail.com
Matt,
I agree. Normally you have a release target, like Release 0.5 and a set of tickets assigned to that release. As enough tickets are closed for that release it will enter an Alpha stage. Once it has a relatively decent amount of stability it will enter a Beta 1 phase. If the software needs a few more refinements before the release it may get a Beta 2 or Beta 3 phase. Finally there is a short lived Release Candidate which some early adopters may try and report back any big problems which will need to be resolved before the final release.
In SVN it may look like this...
tags\release-0.5.0-alpha tags\release-0.5.0-beta1 tags\release-0.5.0-beta2 tags\release-0.5.0-rc
branches\release-0.5.0
It would be good to keep the branches directory uncluttered of every little change and just track the significant releases.
For anyone experienced with SVN, I have some questions.
I am still not comfortable with how SVN handles tagging differently than was done in CVS. I do not fully have an understanding of how branches are different than tags in SVN. Are branches still sticky in SVN? Do tags stay put like they do in CVS?
Brennan
On Sun, 14 Jan 2007 23:34:16 -0600, Matt Kaatman roundcube-dev@matt.kaatman.com wrote:
Hey Eric,
You don't have to release a stable version often, although it is a nice thing to do.
Normally to get to stable you'll freeze new features and have a specified amount of time to squash bugs.
Once the bugs in the tracker are worked out you create a stable release.
If a critical bug is found, you fix it in the stable branch and move the tag.
Matt
Eric Stadtherr wrote:
Matt,
That's an excellent idea in principle; however, the challenge is coming up with the process to decide what's stable. How bad does a bug have to be to prevent a revision from getting tagged? Who does the evaluation? Who "moves" the tag?
Automated unit tests with some scripts that manipulate the repository are usually the answer to this, but the maintenance of unit tests is usually a non-trivial effort.
The easiest thing to do is just keep a working copy of your own, and make your own decisions as to whether something is stable enough for your environment.
Matt Kaatman wrote:
Couldn't you have a tag called stable and move that tag with each
stable
release so that someone who checks it out will always be able to get
the
latest release tagged as stable without picking a specific version?
(So you'd probably double tag with each stable release. One tag with
the
version number that is constant and one that is called stable which moves with each stable release.)
Eric Stadtherr wrote:
Jason,
In general, branches aren't intended for "stable" snapshots - they
exist
as ongoing work areas to manage some parallel development that needs configuration control but cannot impact the baseline. Branches are usually merged back into the baseline when the parallel development is complete. In Subversion, the convention is to create "tags" for snapshots of revisions that have some meaning. If you look in the RoundCube /tags directory, you'll see the latest revision that was considered "stable," i.e. the v0.1-beta2 version.
Jason wrote:
I was checking out svn.roundcube.net and it looks like there isn't a branch that I can checkout/update that'll always give me the latest stable release. Am I missing something, or could a /branches/stable be created that was always the latest stable released version?
Thanks, Jason
Jason wrote:
I was checking out svn.roundcube.net and it looks like there isn't a branch that I can checkout/update that'll always give me the latest stable release. Am I missing something, or could a /branches/stable be created that was always the latest stable released version?
If you want a stable version, then you should go to the download section and not check out from the SVN. I know RoundCube does not publish new releases very often and this is mostly because we have a lot of changes in the code but no proper testing. The SVN trunk actually represents the latest version but may contain bugs. RoundCube versions that were released as "stable" are copied to a branch (like branches/release-0.1-beta2) in order to add important bugfixes to it. We also use branches for developing new features that should not appear in the trunk. Those branches are usually named devel-.... and will be merged back into trunk once the changes are tested and approved.
Tags are not used very often but I usually tag files with a release name. This is slightly different to the release branch which can be checked out and modified with hot fixes. Tags represent the state of the code at a certain point of time, i.e. at the 0.1-beta2 release.
~Thomas
I understand that I can go to the website to get the latest stable version, I'm just saying it would be a handy convenience for those of us who always want to be on the latest released version. If I could check out /branches/stable and it always gave me the latest released version, the same that's on the website, then every so often I could just run "svn up" and know that I'm on the latest release.
Maybe I'm the only one who would find this handy, and if so I have no problem living without it. I just thought I'd throw it out there and see if anyone else thinks this would be as handy as I do.
Thanks, Jason
On 1/15/07, Thomas Bruederli roundcube@gmail.com wrote:
Jason wrote:
I was checking out svn.roundcube.net and it looks like there isn't a branch that I can checkout/update that'll always give me the latest stable release. Am I missing something, or could a /branches/stable be created that was always the latest stable released version?
If you want a stable version, then you should go to the download section and not check out from the SVN. I know RoundCube does not publish new releases very often and this is mostly because we have a lot of changes in the code but no proper testing. The SVN trunk actually represents the latest version but may contain bugs. RoundCube versions that were released as "stable" are copied to a branch (like branches/release-0.1-beta2) in order to add important bugfixes to it. We also use branches for developing new features that should not appear in the trunk. Those branches are usually named devel-.... and will be merged back into trunk once the changes are tested and approved.
Tags are not used very often but I usually tag files with a release name. This is slightly different to the release branch which can be checked out and modified with hot fixes. Tags represent the state of the code at a certain point of time, i.e. at the 0.1-beta2 release.
~Thomas
-
Brennan Stehling -
Brett Patterson -
Eric Stadtherr -
Jason -
Matt Kaatman -
Thomas Bruederli