We are getting close to finishing one version of our product where I
work and we will also be starting the next version. We will actually be
starting the next version before this version is released due to a
strange timeframe of some features. For the most part, mainly just some
bug changes are what's left.
We used to use VSS and for this version of the software we moved to
Subversion. So this is the first time we are encountering this
situation in Subversion. I was wondering, what are the best practices
for handling this? I figure we have to perform some kind of branch of
the Trunk to do this, but I'm not sure what the best way is to handle
both branches.
The way I see it, we have two options. I'm going to refer to the
current version as 1.0 and the next version as 2.0 for simplicity.
1.) Branch the Trunk for the 2.0, making all the changes to 2.0 here
and keep the Trunk running as 1.0.
a. How do we handle changes that go into the Trunk for v1.0 that
need to get in the 2.0 branch right away? Do we make them in both spots
(which could be bad when merging the branch into the trunk after 1.0 is
released)? Do we do weekly merges of the trunk to the branch (making
sure to exclude those revisions when merging back from the branch to the
trunk after v1.0 is released)?
2.) Branch the Trunk for 1.0, making all the changes to 1.0 here and
in the Trunk and run the Trunk as 2.0.
Are there any other options?
Also, how does this affect binary files? We have large number VB6
applications which contain a lot of .FRX files. Performing a lot of
merges could be very bad for these. Option number 2 seems to be less of
a problem for these binary files, but could still have problems. Also,
it seems odd to me to be tagging a Branch for the different builds and
for the final version of 1.0.
So, plainly stated, is there a best practice for how to handle, in
Subversion, starting the next version of a piece of software before the
current version is released?
Thanks,
Shawn Riesterer
Received on Tue May 9 23:08:46 2006