[Numpy-discussion] Going toward time-based release ?
Charles R Harris
Mon May 12 00:42:07 CDT 2008
On Sun, May 11, 2008 at 10:26 PM, Jarrod Millman <email@example.com>
> On Sun, May 11, 2008 at 7:59 PM, David Cournapeau
> <firstname.lastname@example.org> wrote:
> > I would like to know how people feel about going toward a
> > 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.
> > 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
> > first round, if only for seeing how/if it works).
> I was basically thinking about trying this for NumPy 1.2.0, which I
> have been suggesting should be out by the end of August. I am happy
> to serve as the release manager for 1.2. We also need to get a
> release of SciPy out between NumPy 1.1 and 1.2. I hadn't brought this
> up yet, since I have been hoping to get out NumPy 1.1 before starting
> to plan other releases. But I think we are ready to release NumPy
> this week, so now is the time to start this discussion.
> Despite wanting to only take 3 months for 1.2, I believe that in the
> future it would make more sense to have a minor release of NumPy or
> SciPy every three months:
> NumPy 1.1 (May)
> SciPy 0.7 (July)
> NumPy 1.2 (August)
> SciPy 0.8 (November)
> NumPy 1.3 (February)
I dunno. I tend to agree with Mike Ressler that Numpy really shouldn't
change very quickly. We can add new features now and then, or move more
stuff to type specific functions, but those aren't really user visible. Most
work, I think, should go into tests, cleaning up the code base and
documenting it, and fixing bugs. I also wonder how good a position we are in
if Travis decides that there are other things he would rather spend his time
on. Documentation and clean code will help with that. So I really don't see
that we need much in the way of scheduled releases except to crack the whip
on us lazy souls who let things ride until we don't have a choice. If we do
have scheduled realeases, then I think it will also be necessary to draw up
a plan for each release, i.e., cleanup and document ufuncobject.c.src, and
> NumPy will need to work with the last released SciPy (i.e., 1.1 will
> need to work with 0.6) and SciPy can use features from the last NumPy
> release (i.e., 0.7 can depend on 1.1).
> Of course, we need to avoid breaking the API as much as possible. If
> we decided that it is necessary to break the API, we should give our
> users as much notice as possible.
> The one caveat to this is that you may recall I have tried to start
> having a 3 month release cycle ever since I took over release
> management last summer. I was almost able to do it for the first
> release of NumPy and SciPy. But since November of last year, I have
> been struggling to get out NumPy 1.1, which was originally scheduled
> for early February.
> One of the issues that I have faced in trying use the 3 month release
> cycle is that most of us have very busy schedules. But I think that
> we are gaining new developers, which should help alleviate this
> problem. I would be very happy to move to a time-based release
> schedule and would be very happy to help make this happen. I have
> been thinking about this for sometime, so I have a few ideas about how
> to make this happen. I would be very appreciative if you would be
> willing to work with me to get 1.2 out by the end of August.
> Jarrod Millman
> Computational Infrastructure for Research Labs
> 10 Giannini Hall, UC Berkeley
> phone: 510.643.4014
> Numpy-discussion mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Numpy-discussion