[Numpy-discussion] Going toward time-based release ?

David Cournapeau cournapeau@cslab.kecl.ntt.co...
Sun May 11 21:59:27 CDT 2008


	I would like to know how people feel about going toward a time-based
release process for numpy (and scipy). By time-based release, I mean:
	- releases of numpy are time-based, not feature based.
	- a precise schedule is fixed, and the release manager(s) try to
enforce this schedule.

Why ? I already suggested the idea a few months ago, and I relaunch the
idea because believe the recent masked array + matrix issues could have
been somewhat avoided with such a process (from a release point of view,
of course). With a time-based release, there is a period where people
can write to the release branch, try new features, and a freeze period
where only bug fixes are allowed (and normally, no api changes are
allowed). Also, time-based releases are by definition predictable, and
as such, it is easier to plan upgrades for users, and to plan breaks for
developers (for example, if we release say every 3 months, we would
allow one or two releases to warn about future incompatible changes,
before breaking them for real: people would know it means 6 months to
change their code).

The big drawback is of course someone has to do the job. I like the way
bzr developers do it; every new release, someone else volunteer to do
the release, so it is not always the same who do the boring job.

Do other people see this suggestion as useful ? If yes, we would have to
decide on:
	- a release period (3 months sounds like a reasonable period to me ?)
	- a schedule within a release (api breaks would only be allowed in the
first month, code addition would be allowed up to two months, and only
bug fixes the last month, for example).
	- who does the process (if nobody steps in, I would volunteer for the
first round, if only for seeing how/if it works).



More information about the Numpy-discussion mailing list