alfiopuglisi
commented
4 years ago Looking on git I found this:
https://gist.github.com/stuartsaunders/448036/e4978fecf3beacd72ab05a4a45228271a9ce7f00
it's quite complicated, but the basic idea is that there are two parallel branches: one for releases and one for development. Thus all development goes on in the "develop" branch (with additional branching for features, etc), and when a release is ready, someone manually merges everything into master and tags it as a release. Actually this workflow has an additional intermediate step between release and development, to integrate a release in a distributed team. There even is a git wrapper to use a repository in this manner: https://danielkummer.github.io/git-flow-cheatsheet/
I don't know, it might be too complicated for us. But maybe the idea that a release is a specific branch or specific merge to tag could be adopted
On Sun, Apr 26, 2020 at 3:57 PM Lorenzo Busoni notifications@github.com wrote:
We are historically lazy in doing the effort of preparing and realising a package. We should at least try to have an automatic versioning based on some github id/constant/counter related to the latest commit or on the date, in such a way that we avoid having tens of different versions all marked 0.2.0. Maybe something like 0.2.0_200426_155300 is ok (but I'm pretty sure there is an official pythonic way of versioning pre-releases; just grab in the net) This is also a prerequisite to properly release a new pip package: once we'll be happy we can tag the release and it should automatically be build and released with the proper version. Five minutes later we'll find a bug and we should automatically increase the version when releasing the fix
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/ArcetriAdaptiveOptics/arte/issues/14, or unsubscribe https://github.com/notifications/unsubscribe-auth/AARE7WETMZ2NNH76BRZSIJLROQ4UJANCNFSM4MRHUXYA .
We are historically lazy in doing the effort of preparing and realising a package. We should at least try to have an automatic versioning based on some github id/constant/counter related to the latest commit or on the date, in such a way that we avoid having tens of different versions all marked 0.2.0. Maybe something like 0.2.0_200426_155300 is ok (but I'm pretty sure there is an official pythonic way of versioning pre-releases; just grab in the net) This is also a prerequisite to properly release a new pip package: once we'll be happy we can tag the release and it should automatically be build and released with the proper version. Five minutes later we'll find a bug and we should automatically increase the version when releasing the fix