Thank you @scls19fr and @k-bx for all your efforts! Much appreciated! 👍 ❤️

I have three points which we could maybe discuss:

1. Travis or GH Actions?
2. Naming of future repo?
3. Team Members?

Travis

Maybe we should probably use this occasion to setup Travis [...]

Just to let you all know: GitHub has released GitHub Actions now. To see it how we can use it, in my fork I've added an action to release semver to test.pypi.org, see here: https://github.com/tomschr/python-semver/actions

I don't have anything against Travis, it's just another CI we could consider (as we rebuild our repo anyway).

• GH Actions are done completely "inside" GH. If this is a bad thing or a good thing is up to you.
• We can have specific GH Actions in our GH org which is created for our workflow. These Actions just reside in another repo of our org.

Any preferences for Travis or GH Actions? 😉

Naming

If we move the repo from the old to the new organization, it will be named python-semver/python-semver if I'm not mistaken. I think, that sounds a bit strange. For this reason, I would suggest to use python-semver/semver.

Any other ideas?

Team

Another point is do we need teams? Teams can be created with specific permissions. For example, we could create a release team or some admins etc. That makes it a bit easier to distribute the work (of course, communication is still essential).

Maybe we don't need to decide it now, it can be added in the future. With a GH org it's kind of very easy to do that.

Ok, here is a short checklist that may be helpful:

• Move k-bx/python-semver repo to python-semver/semver (?)
• Adapt link to new org/repo in setup.py, documentation, READMEs etc.
• Does the issues and PRs also move to the new org? It does, according to the GH help page.
• Adapt config for ReadTheDocs?
• "Announce" it somewhere? Social channels? Maybe add a short notice in our README?
• Maybe create dedicated teams?
• Adapt config for PyPI?
• Find a better icon for the GH organization. 😉 (low prio)

If you have further ideas, please amend it! 👍

logo should be our top priority 😉😉😉

about doc... github page can also be considered

about doc... github page can also be considered

True, I thought of that as well. I'm not sure how easy is setting it up to store different versions. I haven't looked at ReadTheDocs (RTD), but I assume, it can be a little bit easier.

A lot of documentation for Python modules/libraries resides on RTD. I don't know if people expect that there. Maybe it's up to us and it's a matter of how simple it is to setup either GH Pages or RTD.

Thanks @k-bx for having transfered python-semver.

I personally don't see any problem about having project available at

https://github.com/python-semver/python-semver/

I will now see about CI transfer (still using Travis), url fix...

After this, I will grant @tomschr some rights to test CI using Github actions.

#178 should fix all (most?) links to GH org now.

I have also changed in https://readthedocs.org/dashboard/python-semver/edit/ repository URL
and added @tomschr as maintainer of doc on RTD where he should be able to do some light "experiments" (especially about historization of documentation versions).

@scls19fr Thank you very much! ❤️ 👍 I will read the docs how to host different versions. Will let you know once i'm done. 😉

@scls19fr

maintainer of doc on RTD where he should be able to do some light "experiments" (especially about historization of documentation versions).

I did some light experiments and activated two previous version (2.9.0 and 2.8.1). Just for testing. I think, we should keep 2.9.0 but can delete 2.8.1.

That was easy! Any other wishes? 😉

@tomschr I would keep previous versions - not everyone will have ability to use latest version of package (for instance in case of using package from their distro)

@ppkt Right Karol. Which versions would you keep?

@tomschr let's start from 2.8.1 (however in Debian there is still 2.0.1)

@ppkt That is already the case. 😉 I've enabled 2.8.1 and 2.9.0. Additionally, we have "latest" and "stable", but these are just links to the current 2.9.0 version.

However, that will change of course when we release 3.0.0 (or 2.9.1, whatever).

We had this quite old issue #95 about triggering doc build (at least "latest") at each commit.
Maybe @tomschr you can have a look at this to avoid the need of manually triggering doc compilation.

@scls19fr Ahh, right, I remember. :)
I looked at it and it seems there is a problem with the GitHub Webhook. I've tried to "resync" it, but it seems, RTD needs additional admin permissions for GH which I don't have.

From what I saw, it looks normal in the RTD. Maybe you could try to remove the Webhook and readd it? Maybe that solves the problem.

@tomschr you should now be allowed to remove/add webhook in this repository.

@scls19fr Thanks, I've recreated it, but I couldn't test it. Maybe we should create a 2.9.1 anyway, because the Changelog has a (WIP) label.

high permission high responsibility.
I noticed you @tomschr have 2FA enabled in your Github account which is a very good idea!
Being hacked some times (especially on social networks) I can recommand to @k-bx to do it also.

Not sure publishing a new release just for changing CHANGELOG is worth it.
(I don't have currently access to CLI to publish to Pypi... I currently just have access to GH through website)

Maybe we should tackle "real" issues

Not sure the doc build is automatically triggered
because I merged #178 5 minutes ago but latest doc compilation is still 1 hour, 20 minutes ago according https://readthedocs.org/projects/python-semver/

Not sure the doc build is automatically triggered

I think it did. The last build is 49min back (https://readthedocs.org/projects/python-semver/builds/9913706/) which built commit e2b07af. So clicking the "latest build" of the documentation will bring you always to the last commit on master.

Not sure publishing a new release just for changing CHANGELOG is worth it.

Right, I think my idea is obsolete as the Webhook seems to work (as trying to show it in the previous paragraph).

Thanks for your changes and the trust you put in me. :-)

@scls19fr Can we close this issue? 😉
According to #177 (comment) we have these two open items:

• Maybe create dedicated teams?
• Adapt config for PyPI?

I guess, we don't need teams at the moment. Do we need a special config for PyPI? Or do you see other things that still needs to be fixed for this issue? Thanks!