Versioning and releases

[azukov]

We discussed versioning before. it's probably time to have regular releases.
I propose to tag the current state as 3.0.0 and continue from there.
#44
Please voice your concerns or ideas here. I plan to implement this on Feb 17 unless there are objections.

[austin-hoover]

If this repo is considered a separate entity from python2 repo, maybe v1.0.0 would better? Doesn't matter I suppose.

For the release notes, I guess this first release would be basically backward-compatible with the python2 repo except imports and print statements? In my usage it looks like all class names are unchanged.

I suggest making https://github.com/PyORBIT-Collaboration/py-orbit a "public archive" on GitHub if development has stopped there.

[azukov]

The package name is PyORBIT and the repo is named PyORBIT3. I think it' reasonable to have it installed as PyORBIT 3.x.y - as listed by pip.
Right now python2 repository has a disclaimer about moving to python3, but yes, we can archive it as well.
I wouldn't claim any backward compatibility with python2 version. We can just mention that we use python3 now, different build system and different namespace.

[austin-hoover]

Is the idea that the 3 would never change? If so, then I don't see the purpose of including it in the version number. The package could just be called PyORBIT3 and use the MAJOR.MINOR.PATCH version number.

Actually, what is the purpose of the 3? Could the package just be called PyORBIT?

[azukov]

Currently the package is called PyORBIT after installation. The major version number change assumes no backwards compatibility. Should happen very rare. The minor version number means new features introduces, but full backwards compatibility. The PATCH means bug fix and forward compatibility. The PyORBIT3 was named so that we distinguish from PyORBIT which was python2.
We can stay on v3.x.y as long as we want or we can advance the major. As of now it serves as reminder that it's a "new" PyORBIT

[austin-hoover]

Okay, I'm happy with starting at 3.0.0 then, and I think it would be great to adopt that sort of versioning system.

[juanfem]

as Sasha said, considering that once installed the package is called pyorbit without 3, then I agree it makes things easier to start with 3.0.0

[azukov]

Just made 3.0.0 release.

[austin-hoover]

@azukov pip is telling me I still have PyORBIT-0.1.dev1265+g8991022.d20250408. Does yours start with 3.0?

[azukov]

most likely this happens because your repository doesn't have the v3.0.0 tag in it. It could happen if you are working with your own fork. Or if you haven't updated your local copy after the release was tagged.
I just checked

git clone  https://github.com/PyORBIT-Collaboration/PyORBIT3.git
# setting up environment
pip install .
pip list

gives version PyORBIT-3.0.1.dev10+g833bb2d
run git fetch --tags and then git tag to make sure that you have v3.0.0 in your tree.

[austin-hoover]

Oh, ya I was one my fork. It works with git fetch --tags upstream.