Release Schedule about rootpy HOT 12 CLOSED

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/

from rootpy.

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

from rootpy.

@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.

from rootpy.

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)

from rootpy.

@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.

from rootpy.

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.

from rootpy.

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.

from rootpy.

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?

from rootpy.

Any pointer on how to accomplish that?

from rootpy.

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

from rootpy.

@cdeil, will do.

from rootpy.

@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

from rootpy.