Repo branch mess

[Techjar]

Okay, we can't keep merging things randomly into master or develop, this is just a mess now. The way this model is supposed to work is all new features go to develop first, then develop is merged into master when it's time for a release. Alternatively, you could simply merge everything into master and use tags to specify "stable" releases. This model is probably easier to stick to, and seems to be the way many projects go.

Additionally, you could have two AUR packages: one which builds from a specified version tag, and another which just builds the latest master. The convention on the AUR is to name these g13 and g13-git respectively. Both are still compiled from the Git repo, but the latter implies it's the very latest code, while the former is a specific release version.

[tmackay]

Well, it's not exactly random. bug fixes to master and new features to develop for further evaluation and later merging into master...

[Techjar]

Well, I suppose, but then you have to deal with the awkward situation of develop being both ahead of and behind master. I suppose this model works for large, serious projects that actually maintain long-term support for releases, but for small or "experimental" projects the agile approach works better in my experience. There's too much management and shuffling of commits involved in the structured approach.

[tmackay]

Not to worry, I'll include those new changes now they are in master and submit a new PR to bring develop up to date.

[khampf]

The issue is more one of making us able to test a separate branch while the master branch is supposed to be a known good working version. But hotfixes in master, features in develop is always a good practice. People in general expect a master branch to be somewhat usable and the develop branch an experimental one.

[Techjar]

The way I usually handle experimental stuff is just on a per-PR basis. Test the PR on its own, and only merge it once we know it's good. Do as you wish, I'm just sharing the workflow that works well for me, since things are looking a little messy here.

[khampf]

I try to always develop also up to date wiht master. Hotfixes should not go into develop as it might bring with them experimental not yet completed stuff if both fixes and features live in develop - if you do it that way you absolutely need to also do all new features in separate branches as well.
I have been a bit busy and not rebased properly but in the end - the only things getting messy are the commit messages - not the code .

[khampf]

The reason for there being only the g13 package on AUR is that I was not the one creating the package in the first place. I have just nursed it along following a path of little resistance - while refactoring the g13 daemon as it was depending on boost which I loathe.

• AUR package should depend on release tags
• the master branch gets hotfixes and releases gets tagged every now and then (usually when I have had time to run the daemon myself for at least a week without problems)
• the develop branch has essentially been my personal feature and major changes branch up until now

I am happy that you guys got involved but now that you are - the develop branch and master branch can go out of sync. For now - lets do crazy stuff in either develop or feature specific branches and keep them in sync with master at least on release tags so they never fall far behind.

Does this sound ok?

[Techjar]

Basing the current AUR package on release tags doesn't fit with the -git naming convention. If you go that route then it should be split into 2 packages as I described. Everything else sounds reasonable.

Also, thanks for getting rid of boost, I despise that library as well. Why does anyone use it? libstd provides basically everything you need! My experience with boost has been nothing but long compile times, excessive gcc memory usage, and compatibility problems with different versions of boost.

[khampf]

Yeah the package has been left as is but that is mostly because I have not liked the idea of maintaining more than one package for it - coding is a lot more fun than mantaining ;-)

I could not agree more on the subject of boost. It had a use before libstd got up to like C++17, maybe even C++11 already. Boost has given me so much grief over the years so I try to kill it on sight.