About version naming : if I understood our iirc, we will use the linux
method (1.2 : stable release, 1.3 : unstable release)
Good point, 1.1 releases would be spun out of the rel_1_2 branch and 1.3
releases would be spun out of the rel_1_4 branch. Sorry I wasn't clear
about this.
An other remark : the next stable version will be 1.1.2, from 1.2 branch.
How (chris ?) do we solve this ? We should rename 1.2 branch 1.2.2 (as
it's stable version), and maybe have a 1.1.3 release at anytime (with
partial NT port or partial MARC support for example).
My cut is that the next release should be 1.2.0 (just stabilization and
simple katipo mods). If we can integrate the NT support, we should do
that in the 1.2.X series and backport it from the rel_1_2 tree into the
main line for ongoing support. If people feel strongly, we could call
the first 1.2 release 1.2.2.
Once 1.2 is out and we're comfortable with it, we can start the rel_1_4
tree with MARC support and templates. Shortly after we create the branch,
we should release 1.3.0
Last question : how do we build a version from branch ?
A version is, to me, just a tarball of a given branch at a given
point. It probably needs a bit of cleaning (get rid of CVS specific stuff
and the like), but the work could be scripted
That's what I thought.