Hi, Until now, we have had separate git repositories for syslog-ng on github, one for each major version. This seemed logical at the time, since we do split maintenance, Algernon is doing the maintenance for older trees, whereas I maintain the latest version. Also, this is how I used to do it on my internal trees. However, this complicates things for people who want to follow syslog-ng development, whenever we create a new major release, they have to follow a different repository. Difficult to track forks, see all releases in one place, etc. Since git is perfectly capable of storing multiple major releases in the same git repository, I think it would be the best to let the multiple repositories idea go and stick to a single repository model in the future. To model this idea, I have created this repository on github, and pushed 3.3, 3.4 and 3.5 HEADs here: https://github.com/balabit/syslog-ng Branch names would be as follows: - master: the latest HEAD where development is happening on the latest release - 3.3/master, 3.4/master, 3.5/master: the HEAD for maintained old major releases - topic branches destined for a specific major release would be named 3.X/<branch>, topic branches for the latest version would omit the version number prefix. - tags indicate releases, they are named after the respective release for example: v3.4.5 I hope this makes things simpler for everyone in the long term. If anyone has feedback, I'd love to hear them now, before announcing this to the general public and update references everywhere. Thanks in advance, -- Bazsi
Balazs Scheidler <bazsi@balabit.hu> writes:
Since git is perfectly capable of storing multiple major releases in the same git repository, I think it would be the best to let the multiple repositories idea go and stick to a single repository model in the future.
YAY! This will make my work a lot easier, thank you!
Branch names would be as follows: - master: the latest HEAD where development is happening on the latest release
- 3.3/master, 3.4/master, 3.5/master: the HEAD for maintained old major releases
- topic branches destined for a specific major release would be named 3.X/<branch>, topic branches for the latest version would omit the version number prefix.
Can I suggest we use 3.x/f/<foo> or 3.x/h/<foo> for branch names, and f/<foo> or h/<foo> for master? The f/ thing for features and bigger changes, h/ for hotfixes, just to make it a little bit more clear. Personal preference mostly, but I thought I'd bring it up.
- tags indicate releases, they are named after the respective release for example: v3.4.5
Again, this is mostly personal preference, but would it make sense to switch tagging to syslog-ng-3.4.5 instead of v3.4.5? The benefits are that the tarballs github makes will have nicer names this way (syslog-ng-$VERSION.tar.gz instead of v$VERSION.tar.gz), and also makes it easier for me to see on my prompt where I am, when I'm knee-deep in submodules. But mostly the nicer tarball name... -- |8]
Changing the tag is ok for me, you are doing most of the releases anyway :-) Using f/ and h/ is ok too. On Nov 5, 2013 11:11 PM, "Gergely Nagy" <algernon@balabit.hu> wrote:
Balazs Scheidler <bazsi@balabit.hu> writes:
Since git is perfectly capable of storing multiple major releases in the same git repository, I think it would be the best to let the multiple repositories idea go and stick to a single repository model in the future.
YAY! This will make my work a lot easier, thank you!
Branch names would be as follows: - master: the latest HEAD where development is happening on the latest release
- 3.3/master, 3.4/master, 3.5/master: the HEAD for maintained old major releases
- topic branches destined for a specific major release would be named 3.X/<branch>, topic branches for the latest version would omit the version number prefix.
Can I suggest we use 3.x/f/<foo> or 3.x/h/<foo> for branch names, and f/<foo> or h/<foo> for master? The f/ thing for features and bigger changes, h/ for hotfixes, just to make it a little bit more clear. Personal preference mostly, but I thought I'd bring it up.
- tags indicate releases, they are named after the respective release for example: v3.4.5
Again, this is mostly personal preference, but would it make sense to switch tagging to syslog-ng-3.4.5 instead of v3.4.5? The benefits are that the tarballs github makes will have nicer names this way (syslog-ng-$VERSION.tar.gz instead of v$VERSION.tar.gz), and also makes it easier for me to see on my prompt where I am, when I'm knee-deep in submodules. But mostly the nicer tarball name...
-- |8]
______________________________________________________________________________ Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng Documentation: http://www.balabit.com/support/documentation/?product=syslog-ng FAQ: http://www.balabit.com/wiki/syslog-ng-faq
Balazs Scheidler <bazsi77@gmail.com> writes:
Changing the tag is ok for me, you are doing most of the releases anyway :-)
Using f/ and h/ is ok too.
Lovely, I'll update my repo accordingly as well, and likely move a few stuff over to balabit/syslog-ng. Thanks! -- |8]
participants (3)
-
Balazs Scheidler
-
Balazs Scheidler
-
Gergely Nagy