Github branches - Commit policy

[garvinhicking]

Hi!

I just moved around the github structure.

I renamed the old "master" to "1.7" which will now carry on possible patches for the 1.7.x tree, if there ever is a need (probably/hopefully not, as we will promote upgrading to 2.0).

The old branch "2.0" was then moved into "master", keeping the history of 2.0 development (and earlier) intact. The "2.0" branch was kept, and similar to 1.7 and 1.6 will provide patches for the 2.0.x line, whereas we will continue developing a future 2.1.x series with newer unstable patches.

To rephrase, we now have these branches to commit:

* 1.7 - this will get any major security-related bugfixes for the 1.7.x series
* 2.0 - this will get any bugfixes (security related or not) for the 2.0.x series
* master - this will get bugfixes and possible new, experimental changes which are basically tested and the developer feels good for users to test. It's the next 2.1.x series.

I want to encourage the use of feature branches for larger commits that are untested and would possibly "break" master. Each major feature should best get its own feature branch, so as soon as patches work, they can be merged back into master. I'd like to first discuss on what should be a feature branch or not on a per-feature basis, so that we can all weigh in on whether to create a new feature branch, use an existing one, or whatever. This is so that we do not get too many branches which make testing the whole set of features too hard.

For developers, if you commit something, this should be your decision tree:



What do you think, is this agreeable?

[onli]

Looks pretty good to me, at least like something we should try out for a while and see whether the feature branch approach works for us

[Timbalu]

Good for me too!
About the feature branches, I think this will possibly never happen (since only being used in large rewrites). An Alpha is an Alpha and what isn't satisfying working yet will get fixed together...

[yellowled]

This will sound way more opposed than it's supposed to. Just some quick ideas (I don't have much time now):

I renamed the old "master" to "1.7"

Does it make sense to name it “1.7”? We will most likely never support more than one older version, but at some point, 2.0 will become the older version we still keep around. I think it would make more sense to name this “oldstable” or “lts” (long term support) or something.

Other than that, I like the approach. I assume that we'll drop 1.7 support somewhere down the road, though, and I strongly suggest that we think about if we want to continue maintaining more than two branches then. Also, we should try to avoid developing future versions in a seperate branch in the future. 2.0 was an exception because it was a really huge change, but maintaining the 2.0 branch also was kind of a hassle. I'm sincerely surprised how quicky the merge went.

In that light, “2.0” might also not be an ideal name for the branch to hold security updates in the long run, because that as well will at some point no longer be 2.0. Maybe call it “stable”?

As for the feature branches, yes, please. For the time being, we should try to create feature branches that do not affect other areas, if possible, to avoid having to merge feature branches with other feature branches (we discussed this briefly in the devtalk, I'll assume you know what I mean).

YL

[garvinhicking]

@Timbalu - We'll need to see...if there's some things that could really make things problematic for others (ie. a new permission management system, new database layer etc.) we should really discuss. In many cases we got along without feature branches, but in 2.0 this lead to a very very long development cycle, so maybe we can shorten things if we don't open up two many places at once but work on each major feature on its own. But this is highly theoretical, we'll see how we can deal with this on a per-feature basis.

@Yellowled - I'd really like to stay with our old workflow, especially because my release scripts are made for this and people can work easier with github checkouts on their systems without unwanted interruption. By using branches that match the version series we can more easily drop specific versions, by outsourcing them to a branch. The 2.0 branch will get the 2.0.x maintenance branch for every minor version, and we only backport bugs and security issues while developing new features in "master" like we did before the huge 2.0 rewrite. So a developer ideally only has to focus on "master", and sporadically backport important security fixes to the specific branch.

I want to drop 1.7.x completely a few weeks after 2.0 release when things settle down. 2.0 will then also be quickly put into "maintenance" mode, so that development on 2.1 can implement our github "Future" things...

Having a "stable" or "oldstable" would mean at some point we'd always have to deal with conflicts etc. because 2.0 would be merged to "oldstable" at some point, that's a huge hassle because "stable" will contain different versions. By using a "1.7" and "2.0" branch, those will ALWAYS contain 1.7.x and 2.0.x so users who checked that out will not eventually jump from 1.7 to 2.0, unless they intentionally switch the github branch to 2.0, which is the suggested way...

[yellowled]

In many cases we got along without feature branches, but in 2.0 this lead to a very very long development cycle, so maybe we can shorten things if we don't open up two many places at once but work on each major feature on its own.

I don't think we'll ever have a development cycle as long as for 2.0 again. At least we should try to plan to avoid that. I don't know about you guys, but at the end, it felt really exhausting, and I think it may even have led to some decisions being made more quickly just to get it over with (which is fine, I just don't want that again).

I'd really like to stay with our old workflow, especially because my release scripts are made for this

Okay. Anything to make maintaining automatable.

I want to drop 1.7.x completely a few weeks after 2.0 release when things settle down.

Oh, okay. I was assuming we'd keep 1.7.x around longer. In that case, nevermind.

YL

[Timbalu]

I want to drop 1.7.x completely a few weeks after 2.0 release when things settle down.

Oh, okay. I was assuming we'd keep 1.7.x around longer. In that case, nevermind.

A few weeks only...? Give us all some more time, please!
It doesn't hurt having some more time checking out possible flaws or inventions between old and new stable, without having to dig through hundreds of commits. There is no real benefit in purging this early.

[garvinhicking]

Hi!

A few weeks only...? Give us all some more time, please!

No, really - I see 2.0 as a release that users NEED to migrate to, because 1.7 is practically dead, it gets no new features. Of course if there are serious security issues, they will get fixed in 1.7 - but other than that, smaller bugfixes will not get put to 1.7. This is just a waste of precious time, maintaining a seperate tree with commits.

The old 1.7 tree is always there, so things can easily be checked out there, but it will not be developed any further. The history/branch/tag of 1.7 will be preserved for as long as we use github.

[Lux]

To rephrase, we now have these branches to commit:

* 1.7 - this will get any major security-related bugfixes for the 1.7.x series
* 2.0 - this will get any bugfixes (security related or not) for the 2.0.x series
* master - this will get bugfixes and possible new, experimental changes which are basically tested and the developer feels good for users to test. It's the next 2.1.x series.

This is so much different from every other project I know that I made a mistake and run 2.1alpha now in my blog.

What I see in other projects is:

* master - this is the current stable release
* 1.7 - this is the stable 1.7 release (tag and branch)
* 1.7.1b - this is the beta release for 1.7.1 (only branch)
* 2.0b - this is the beta release for 2.0 (only branch)

In my opinion it would be better to have a stable master und development branches being unstable or in status "testing".

In case 1.7.1 comes, the branch 1.7 would be deleted, but the not the tag. This gives the opportunity to go back to every version.

Cheers

Dirk

[garvinhicking]

In any case for the future we need two branches, one for 2.1 and one for 2.0.x.

So you're basically suggessting to move the current "master" to a "2.1" branch, move "2.0" to the "master" branch and then in the flowchart replace the same?

I must admit I'm a bit afraid to move 2.0 to master (and effectively removing the branch) by maybe losing commit history to that branch. Other than that, I feel we as developers always focus on the next major release, and "master" represents to me the most important working state.

I agree that I've also seen many projects that use master as the stable line, but I've also seen many proejcts that use master as the "lifeline".

Since we often support a previous stable line for a long time, in github by default users visit the "main" trunk, and if they'd see the last commit is a year ago, they would think the project might be dead, but instead in our active release we are working much harder, so that's also some PR issue.

To sum it up, I don't really feel comfortable with changing this. My proposal was that "master" would always be in a "runable" state, everything that breaks thing would go into feature branches, so people who dare to checkout "master" should actually be rewarded by getting the latest and greatest, maybe not thoroughly tested, but at least so that the implementing developer thinks this is ready for testing by others. We also need feedback by users, so actually it would be a great thing if people "accidentaly" run master for us. I assume those who run github checkouts on their blog actually follow the development of Serendipity and are able to make backups so that nothing really would happen to them.

(I very much appreciate your opinion on this, my posting is not meant to be derogatory)

[Lux]

In any case for the future we need two branches, one for 2.1 and one for 2.0.x.

No, even more, there would be a branch for 1.7 as well.

So you're basically suggessting to move the current "master" to a "2.1" branch, move "2.0" to the "master" branch and then in the flowchart replace the same?

This is close to what I ment.

Currently 1.7.8 is stable, so I would expect this to be master.

Branches without a letter "b" for beta and "a" for alpha stand for stable branches.

I must admit I'm a bit afraid to move 2.0 to master (and effectively removing the branch) by maybe losing commit history to that branch. Other than that, I feel we as developers always focus on the next major release, and "master" represents to me the most important working state.

Agreed, please do not delete anything, it should moved "git branch -m".

I agree that I've also seen many projects that use master as the stable line, but I've also seen many proejcts that use master as the "lifeline".

Since we often support a previous stable line for a long time, in github by default users visit the "main" trunk, and if they'd see the last commit is a year ago, they would think the project might be dead, but instead in our active release we are working much harder, so that's also some PR issue.

To sum it up, I don't really feel comfortable with changing this. My proposal was that "master" would always be in a "runable" state, everything that breaks thing would go into feature branches, so people who dare to checkout "master" should actually be rewarded by getting the latest and greatest, maybe not thoroughly tested, but at least so that the implementing developer thinks this is ready for testing by others. We also need feedback by users, so actually it would be a great thing if people "accidentaly" run master for us. I assume those who run github checkouts on their blog actually follow the development of Serendipity and are able to make backups so that nothing really would happen to them.

(I very much appreciate your opinion on this, my posting is not meant to be derogatory)

I see and understand your points.

Please keep in mind that we could have some (more than one) stable branches.

At least 1.7 and 2.0.

How do you want to reflect that?

Cheers

Dirk

[garvinhicking]

Hey,

Please keep in mind that we could have some (more than one) stable branches.
At least 1.7 and 2.0.

Yes, that's how it currently is: 1.7 is the branch for 1.7.9+ (if ever), 2.0 for any 2.0.x release (the now primary stable as 2.0 was released today), and then for every new stable release a 2.1, 2.2 etc. branch will be created, at least that was my original intention.

Regards,
Garvin

[yellowled]

Most of the projects I follow on GitHub use the approach we intended to use for the future. (Disclaimer: I don't follow many projects on GitHub, and those are a bit less complex than s9y.) Meaning they keep the bleeding edge in master, so if you check out master or download a master zip file, you get the current state of development. Stable, “reliable”, tested versions are done using GitHubs releases feature.

I tend to see GitHub mainly as a tool for developers, so it should be used the way developers can work comfortably with it. It should especially make maintaining releases as easy and automatable as possible, which is why we usually let Garvin take the lead on this (because he does the releases and scripts for that).

I can, however, see that it might lead to confusion for people who use GitHub to either get the most recent stable or who want to deploy their productive blog using a git checkout. Hmmm …

(Not very helpful, I know. Just wanted to chime in on it. Need to think more about this.)

YL

[Lux]

I tend to see GitHub mainly as a tool for developers, so it should be used the way developers can work comfortably with it. It should especially make maintaining releases as easy and automatable as possible, which is why we usually let Garvin take the lead on this (because he does the releases and scripts for that).

It is just a matter of philosophy, I think.

In case we encourage people to use a checkout from GitHub we have different prerequisites to GitHub only used by developers.

I am not a developer but an eager tester and I like to test from beta status on because of testing with my productive blog, most fixes to bugs appear close to instantaneously on GitHub, so I need GitHub to do proper testing.

Currently I see at least three types of "users":

* Developers need access to everything
* Testers need access to betas and fixes
* Endusers need access to stable (and sometimes to fixes)

Agreed?

Cheers

Dirk

[yellowled]

Currently I see at least three types of "users":

* Developers need access to everything
* Testers need access to betas and fixes
* Endusers need access to stable (and sometimes to fixes)

Agreed?

Yes, but not all of those need a seperate branch. Most end users probably don't use a git checkout, so they could just use release zip files (we can do those pretty confortably on GitHub as well, we don't need to wait for SF).

That leaves us with devs and testers. Devs usually “need” (I think “prefer” is the better term) the current state of development. Testers usually need the upcoming stable. If I'm not mistaken, this could be done with our current setup (master = current state, 2.0 branch = next stable) – but testers using a git checkout would need to use the 2.0 branch, not master.

What that leaves us with is whether people (meaning devs or testers) are more used to having the current state in master or not, right?

YL