[Bioperl-l] 1.5.0 release
Jason Stajich
jason.stajich at duke.edu
Mon Jan 24 09:54:35 EST 2005
I'll make this on-list to hopefully clear some of this up.
Aside, I don't have a lot of time to debate the philosophy here. I
really never intended to be release weenie for this release so if folks
have a strong opinion about how it should be done, please also consider
being the next release-master.
1.5.0 (and all the release-candidates 1.5.0-RC1 and 1.5.0-RC2) are made
off the HEAD of the CVS tree. Remember HEAD is the default branch you
get when you do a CVS checkout. You can type 'cvs log SOME-FILE' to
see all the tags that have been applied to a file. The webcvs -
http://cvs.open-bio.org/ - also shows this graphically if you prefer.
So 1.5.0 will have all the changes made on the HEAD - this means all
the changes since we branched for 1.4 sometime last year. If we
release another developer release before doing 1.6 I would think we'd
still name it 1.5.1 (scenario B below) just organize things, but it
might have a separate tag. Scenario A is what we do with stable
releases where we make a branch tag and then all releases on that
branch are derived from the 1.4 timepoint.
A)
--------------------------HEAD---->
\
1.4 tag (branch)
\
1.4.1 tag
B)
--------------------------HEAD---->
\ \
1.5 1.5.1
WRT specifics of the next releases. The idea is that 1.5.0 goes out and
people play with it, but we haven't christened it as a 'stable'
release, meaning not all the functionality in releases after 1.5.0 will
behave the same. While we pledge that when 1.6.0 is ready, it will be
stable and around for a while, and IDEALLY not break any code you
wrote against the 1.4.0 library. Some recent commits to the HEAD of
bioperl negate this so we will probably have them backed out of the
stable release.
The developer release is just one step easier than CVS checking out so
if you already run your code from a CVS checked out directory this
isn't going to make your life better. If you are unable to run things
in-house unless they have a on official "RELEASE" stamp or if you can't
use CVS, then 1.5.0 is for you. If you want the latest functionality
in order to use the latest GBrowse release, 1.5.0 will be for you. If
you are happy with your current Gbrowse setup, don't run this on your
production server until you have tested things. If you are very
conservative, run an important pipeline of analysis in-house that
relies on Bioperl, and it is currently working great - you DON'T need
to update to 1.5.0. In fact, don't do it in a production environment,
but give the developer release a spin in a, well, development
environment.
Most importantly we want people to try out the release and really use
it like they would in production environment, then tell us what breaks.
Doing this lets the 1.6.0 release really be what you hope and yearn
for.... =)
A policy.
What I would like to do in the future when preparing for a stable
release is start to branch early - say 1 to 2 months before - and
require changes on the branch to be only bugfixing or Well-Thought Out,
and in general no API changes that remove functionality, GainOfFunction
(GOF) probably allowed. Also remember the even numbered releases are
stable releases, odd numbered are developer releases and don't go out
to CPAN. We don't make API changes on the branch so that 1.4.1 is
completely compatible with 1.4.0. I care less about GOF on the branch
as long as it doesn't break anything.
Instructions and Mechanics of how to do all of this with CVS.
See this page: http://bioperl.org/UserInfo/CVShelp.shtml
How do you get things on the different branches.
Let's see what branches are around:
[jason at lugano core]$ cvs log README
RCS file: /home/repository/bioperl/bioperl-live/README,v
Working file: README
head: 1.36
branch:
locks: strict
access list:
symbolic names:
bioperl-release-1-5-0-rc2: 1.36
bioperl-release-1-5-0-rc1: 1.36
branch-1-4: 1.34.0.2
bioperl-release-1-4-0: 1.34
bioperl-devel-1-3-04: 1.34
bioperl-devel-1-3-03: 1.34
bioperl-devel-1-3-02: 1.33
bioperl-devel-1-3-01: 1.33
bioperl-release-1-2-3: 1.30.2.4
bioperl-release-1-2-2: 1.30.2.3
bioperl-run-release-1-2-0: 1.32
bioperl-release-1-2-1: 1.30
bioperl-1-2-1-rc1: 1.30
branch-1-2-collection: 1.30.0.6
bioperl-release-1-2-0: 1.30
branch-1-2: 1.30.0.2
bioperl-devel-1-1-1: 1.27
bioperl-release-1-1-0: 1.23
bioperl-release-1-0-2: 1.20.2.7
bioperl-release-1-0-1: 1.20.2.7
bioperl-release-1-0-0: 1.20.2.6
bioperl-1-0-alpha2-rc: 1.20.2.1
We name branches with a 'branch-' prefix. The releases have the word
'release' in them. Hopefully that is clear!
So if you check out from a branch it means you get the most up-to-date
code from the branch (if there were additional commits after the point
in time when you made this tag, you'll get them) while a release-tag
gets code at particular finite point in time.
Try to get the 1.4 release (with a CVS account).
The cmd line options we are using after 'checkout'
-r BRANCH-NAME OR TAG-NAME)
-d DIRECTORY-NAME
REPOSITORY-NAME
% cvs -d:ext:YOURNAME at pub.open-bio.org:/home/repository/bioperl
checkout -r branch-1-4 -d bioperl-1.4 bioperl-live
If you want do this via anonymous CVS (no read-write access)
% cvs -d:pserver:cvs at cvs.open-bio.org:/home/repository/bioperl checkout
-r branch-1-4 -d branch-1.4 bioperl-live
Now if you want to make a change on the branch you HAVE to make those
changes in that directory we checked out: "bioperl-1.4"
When you check them in you do the normal CVS commit.
If you want to merge your changes back onto the main trunk after you've
made changes on the branch (or vice-versa, flip-flop the directory
names)
1. check in your changes on the branch
2. Go to the OTHER directory you have where the HEAD code is checked
out (called 'bioperl-live' in this example)
% cvs -d:ext:YOURNAME at pub.open-bio.org:/home/repository/bioperl
checkout bioperl-live
3. do an update to merge the changes from the branch, let's merge
changes in Bio/SeqIO/swiss.pm to the HEAD from the branch
% cd bioperl-live
% cvs update -j branch-1-4 Bio/SeqIO/swiss.pm
RUN THE TESTS
% perl -I. -w t/SeqIO.t
.... all tests pass ...
% cvs commit -m "merged changes from 1.4 branch regarding
this-and-that" Bio/SeqIO/swiss.pm
Done. Reverse the directory and branch names to merge from the HEAD to
the BRANCH
% cd bioperl-1.4
% cvs update -j HEAD Bio/SeqIO/swiss.pm
% cvs commit -m "merged changes from HEAD to branch regarding
this-and-that" Bio/SeqIO/swiss.pm
Hope that helps some.
-jason
On Jan 24, 2005, at 9:15 AM, Sean Davis wrote:
> Jason,
>
> I'm sorry to bother, but what is the current CVS tag system with
> regard to bioperl? For example, if I do a CO on Monday of
> bioperl-live, what do I get? I have always worked from bioperl CVS
> code, so just wanted to make sure that the tags weren't going to
> change and, if so, what is going to be what. I wasn't sure if this
> should go to the list....
>
> Thanks,
> Sean
>
> ----- Original Message ----- From: "Jason Stajich"
> <jason.stajich at duke.edu>
> To: <bioperl-l at bioperl.org>
> Sent: Sunday, January 23, 2005 9:55 PM
> Subject: [Bioperl-l] 1.5.0 release
>
>
>> If there are some more outstanding commits before we roll 1.5.0 out,
>> please let me know. Otherwise I'll tag and release the 1.5.0 tarball
>> Monday. This is a developer's release so it does not have to be
>> completely perfect.
>>
>> -jason
>> --
>> Jason Stajich
>> jason.stajich at duke.edu
>> http://www.duke.edu/~jes12/
>>
>> _______________________________________________
>> Bioperl-l mailing list
>> Bioperl-l at portal.open-bio.org
>> http://portal.open-bio.org/mailman/listinfo/bioperl-l
>
>
>
--
Jason Stajich
jason.stajich at duke.edu
http://www.duke.edu/~jes12/
More information about the Bioperl-l
mailing list