[Tcllib-devel] Tcllib development and release policy discussion ...

[Andreas K. <and...@Ac...>]

At the end of this mail is a discussion Don Porter and I had on the
Tcl'ers Chat today. The gist of the discussion (and also proposed
modus operandi for the future) is:

*	Create a branch named RELEASE, now.

*	All future development on tcllib happens in the branch HEAD
	(or developer-derived subbranches of HEAD)

*	Whenever a maintainer for a module and/or package is
	satisified with the current state of his module/package
	an internal release is done which merges the relevant
	parts of the HEAD into RELEASE.

	After the internal release the version number of the merged
	packages and/or modules is incremented to distinguish the
	current development version from the released version.

	For each internal release the developer doing the release
	has to add a note to the file MERGES (in the RELEASE branch).

*	The release manager (RM) of tcllib uses the MERGES file to
	determine if enough or important changes have accumulated
	to warrant a patch, minor, or major release of Tcllib itself.

	When doing such a release the RM

	-	branches the new release of RELEASES
	-	updates the version information in the new branch
	-	and generates distributions.

We are not yet quite on the same page when it comes to the version
number of Tcllib itself.

Diagram ...

	----\-----------\------------------------ HEAD
	     \           \ aperiodic merges
		\           V
             \------\-----------\-------------- RELEASES
                     \           \
                     tcllib-1.2   tcllib-x.y


If there is no veto, or a better idea, this model will start just
before tagging 1.2.


--
	Andreas Kupries <and...@Ac...>
	Developer @ http://www.ActiveState.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
dgp	aku here?
steveo	later all, everyone have a good weekend!
	steveo has left the chat!
aku	I'm here
dgp	I'm bumping control back to 0.1.
aku	Reason ?
tclguy	what went wrong?
dgp	control 0.1 has never been released.
aku	Not even as part of Tcllib 1.1 ?
tclguy	ah, who cares about the start number though.
dgp	tcllib 1.1 included control 0(.0)
aku	Oh.
aku	Sure, do it. It is not tagged yet.
dgp	This is the issue we need to sort out about releases of the packages in
tcllib.
dgp	It's unlikely that all packages will be in releasable state at the same
time.
dgp	Unless they're all stagnant.
tclguy	how so
dgp	So, we need a branch where we can do development, and then be able to
internally "release" them as able to be included in tcllib releases.
tclguy	ah, well that's ok.
dgp	As an example, I'd prefer that control::rswitch not be included in any
real releases.
dgp	But I do want it on the HEAD so we can keep working on it.
aku	So we should have HEAD for development, and also a general RELEASE
branch and for each new release things are merged from HEAD to RELEASE,
tagged and new branch created for that particular release ?
dgp	Yes.
dgp	I'd say that as the "co-ordinator" of tcllib, your job would be just to
package up the tip of the RELEASE branch, on whatever time-table is good for
you.
dgp	Then each package maintainer can decide when they've got a stable
snapshot to move over to RELEASE, completely asynchronously with tcllibs's
release schedule.
aku	And the developers do the merges at their leisure.
aku	cross-message
dgp	I've meant to get this mentioned several times, but my focus hasn't been
on tcllib lately. Sorry.
aku	Whe should have a file where maintainers record the merges they have
done since the last release of the RELEASE branch. That way the release
manager just has to look there to decide if there is enough for a new
release.
aku	Well, we can start after 1.2 using that scheme if the others agree. I
will post to tcllib-devel.
dgp	Makes sense to me.  Also, the tcllib RM might have to "beat the bushes"
if there's been no new release for a while, yet new features are on the
HEAD.
dgp	On the version number, I like the pattern of bumping numbers right after
a release so that CVS snapshots are distintinguished from released versions
by [package].
dgp	For tcllib 1.2, is it too much trouble to have control/rswitch.* removed
before release?
aku	So, initial import is for example 1.0. Release ... Bump to 1.1 ... Devel
... Release .. Bump 1.2 ... Devel ...
aku	How to do this ?
aku	Special branch right now ?
dgp	Note that we are working on Tcl 8.4a4 on the HEAD; that's all I mean.
dgp	Yes, now that you mention it.
dgp	You will tag the files that make up the tcllib-1.2 release.
dgp	Make that tag the branch point for creating the RELEASE branch.
aku	Yes, that should work.
dgp	sadly CVS merging off the HEAD doesn't work well at all..
dgp	Simplest approach seems to be just copying file between 2 sandboxes.
dgp	Or there may be a way to make cvs update -j work, I'll need to
experiment.
aku	IOk.
aku	Slightly different topic: The process we have just discussed should be
good enough for patch and minor releases. But what about changes which
warrant a major release of tcllib ? I believe that for these more
coordination is necessary.
dgp	Keep in mind that tcllib is not a package.
dgp	It's just the umbrella name of a distribution of packages.
dgp	As such, I think you can use whatever numbering system you like, for
whatever purpose you need to fulfill.
dgp	If you want to keep similar spirit as the package numbers, though...
aku	We can do "package require Tcllib" right now. It is treated as a sort of
virtual or super package
dgp	I'd increment tcllib's major version number whenever you drop from it a
package that was in previous releases.
dgp	Hmmm.... well, then stop that.  That makes little sense, and leads to
crap like we encountered in tclhttpd.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~