Release Schedule

[ndawe]

rootpy has been released once as version 0.6:

http://pypi.python.org/pypi/rootpy/0.6

We should start thinking about when we would like to have a 0.7 release out and what deliverables could be ready. Also this might be a good time to consider various versioning schemes. My original plan was to have 0.7, 0.8, 0.9 and then 1.0 would be the first "production-ready" release. Anyone oppose this plan? I'm open to other suggestions. Ubuntu's versioning is convenient (as @pwaller has pointed out) since the version is the date and therefore you know how old a version is without looking it up.

Once we have a concrete plan we can outline the release schedule and deliverables on our github wiki.

[cdeil]

Let's use the 0.7 milestone we already have:
https://github.com/rootpy/rootpy/issues?labels=&milestone=1&page=1&state=open

How about aiming for the 0.7 release in 10 days?
We can add open issues to 0.7 or defer some to 0.8 in the next days as we go along.

root_numpy should be released simultaneously and get the same version number, to make things simple for users.

I think we schould stick to the simple 0.7, 0.9, ... scheme, this works with pypi, pip and all package managers:
http://www.python.org/dev/peps/pep-0396/

[pwaller]

I agree with 0.7. "Classic" version numbers have their place, too, for indicating API breaking changes vs bugfixes/small features vs complete rewrite.

[cdeil]

@piti118 I see version='2.00' in root_numpy/setup.py. As far as I can see there is no "official release" on pypi though yet. What do you think of changing to 0.6 now so that version number can get in sync with rootpy? I know it's bad practice to do this now, but IMO it's worth it.
Also I think it would be good to have a root_numpy 0.6 release before the joint rootpy / root_numpy 0.7 release, just to make sure e.g. pip-install works fine.

[piti118]

I don't have any preference on version number... but why would having the same version number make things easier? (I have no idea how PIP works)

[cdeil]

@piti118 The only reason is that then it's obvious to the user which root_numpy and rootpy versions are compatible.

pip doesn't care if the version numbers are in sync, root_numpy simply will be an optional dependency of rootpy, and declaring root_numpy >= 2.0 for rootpy 0.7 would work.

[piti118]

But rooypy is more framework; it will be rapidly developed and have features added for a long time
while root_numpy is more library; all it does is provide core functionalities. It will move much slower than rootpy if it does move at all. (Think of numpy and matplotlib)

If you fix the two version numbers, the two will move apart very soon.

But, again version number doesn't really matter to me though. You can change it but I still don't see the benefit.

[ndawe]

I think it's ok for root_numpy to stick to its own versioning for that reason. We wouldn't want to release a new version of root_numpy only to increment the version along with rootpy even if nothing changed in root_numpy.

[cdeil]

I agree, version numbers would get out of sync quickly anyways, so let's simply keep root_numpy at 2.0.

Can you make a root_numpy release on pypi though?

[piti118]

Any pointer on how to accomplish that?

[cdeil]

@ndawe Can you make a short "HowTo make a release" on our wiki?

[ndawe]

@cdeil, will do.

[cdeil]

@ndawe Some other projects have already written up the steps / commands to do a release. If what you do for rootpy is similar, maybe it's a useful starting point (or if it's identical you can simply link there from our wiki or developer docs):
http://docs.astropy.org/en/latest/development/building_packaging.html#release
http://ipython.org/ipython-doc/dev/development/release.html