...
I have to agree with Matthew that:
- Nobody wants to break master because its what everybody is using.
Problem is that if we had a development branch nobody would be using it because it might break, so its insufficiently tested. I don't have a solution to that.
master *is* the development branch. It's not a stable branch that must not be broken at all costs. It's also not true that everyone is using master. The vast majority is using releases, and in fact we do regular releases so that we can use master as a true development branch.
The vast majority are therefore not testing anything in master prior to release, so they are not helping stabilise the release. Thats no help. (Of course users are not expected to help stabilise the release).
Even I don't use master (a very regular contributor) for my clone that I use daily. I always fork the last release, merge my changes, and backport individual commits from master (via cherry-pick). Of course I develop features based on master, so I do test the master branch on a regular basis.
So you don't do much testing of any changes in master, except those you choose to backport to your day to day version, or that you happen to use when testing your own Geany development.
Some of us do use git HEAD (or close to, I'm a bit behind ATM) so we do check what will be in the next release, at least for those things in our normal workflow. Otherwise if nobody used HEAD it would be extremely lightly tested come release time.
Besides emacs and atom I havn't looked at how other editor projects do it.
But certainly emacs has most of their devs using HEAD or close to it, and they also try to be careful about what they commit. But of course thats not a github project so they get fewer external contributions and most have been through mailing list hell before they get applied.
Atom takes a different approach of being very modular and having each part in a separate repository, over 200 according to their CONTRIBUTING.md. Therefore its more akin to geany-plugins, where individual parts can be easily handled separately. And they seem to make heavy use of feature branches in the main repos. Don't think that will work with a monolithic C application like Geany.
So yes, if you are afraid of doing development on the development branch, it's clear that we're struggling to get anything done. Sure, one can expect that PRs are perfect before getting merged, but the current situation shows that this is not working if you want to get something done in a timely manner.
It seems that the result of what you are advocating is to release less tested more buggy versions? Or am I misunderstanding the result?
From another angle, both of you could easily create a development branch. But you didn't so far. Anyway, how is that workflow supposed to work? If lots of PRs go through an intermediate branch then merging that intermediate branch into master is going to be a nightmare too.
Which is also true and another reason its not done that way.
Cheers Lex
Best regards.
Devel mailing list Devel@lists.geany.org https://lists.geany.org/cgi-bin/mailman/listinfo/devel