[Numpy-discussion] Going toward time-based release ?
Sun May 11 23:42:44 CDT 2008
On Sun, May 11, 2008 at 11:14 PM, Mike Ressler
> Numpy doesn't (and probably shouldn't) change that rapidly. I would
> really hope that the core numpy is solid, stable, and predictable. I
> like major and minor version numbers that indicate a major change is
> coming. If it's only a minor version number change, I know that I can
> update it safely and go merrily computing on my way. "2008.04" doesn't
> tell me if it is a minor bug fix or a major blow to my sanity.
> So, please, if at all possible, keep the feature numbering. Thanks for
> hearing me out.
We will be keeping the major.minor.micro version numbering. David is
not proposing to change that. What he is suggesting is that we try to
make these releases come out on a given schedule.
The semantics of major.minor.micro for numpy got confused because of
an early mistake (IMO) wherein we designated 1.1 as a release which
would allow code breakage. I would very much like to get away from
that and follow Python's model of only doing bugfixes/doc-enhancements
in micro releases, new features in minor releases and code breakage
never (or if we absolutely must, only after one full minor release
with a deprecation warning).
I think it is certainly feasible to roll out the bugfix releases on a
fixed schedule. I am less certain about the feature releases; I'm not
sure we gain much by it. Having a feature freeze policy is sufficient,
IMO. Once we've decided that we have accumulated enough features for a
release, we declare a feature freeze for a fixed period of time,
test/build/bugfix, then release. I think a fixed recurring time period
may simply encourage rushing features in without testing.
"I have come to believe that the whole world is an enigma, a harmless
enigma that is made terrible by our own mad attempt to interpret it as
though it had an underlying truth."
-- Umberto Eco
More information about the Numpy-discussion