Hi All,
Now we have 0.21 released I thought it was worthwhile looking at the path ahead, and since we have the possibility of some quite significant changes, maybe starting a plan of attack so that not too much effort is wasted.
The big things I see right now that have had some work are:
1. change to DVCS and hosting, and possible changes to process that forces/enables (to my mind the process issues are more important than the DVCS itself)
2. change to Glade 3 (entails GTK change)
3. support for GTK3 (needs above and might entail a further GTK change)
4. support for plugins in non-C, non-compiled languages (as full plugins, and the VM/interpretor as a plugin itself so core doesn't need to be changed to add more languages)
5. session support (has been sitting in a branch for a while)
6. patches in the queue (some are getting a bit old)
7. bugfixes
8. call it 1.0
roughly from the most disruptive to least disruptive.
Then there are all the bright new things that will inevitably come up :)
My main suggestion is that it would be best to do the change to the VCS first, then it won't disrupt the other things. And get the process bedded down (stable branch, develop branch, version branches ...) and call that 1.0.
And then other disruptive things can then be done in repository forks so they don't get too much in each others way.
Beyond that its up to individuals which they work on and when, Geany is an open source project after all.
So I suggest that we decide DVCS and host (Git, Github?) and follow the recipe developed in the ML as soon as possible. And then announce the change, and the new processes.
Cheers Lex
Hi Lex,
Agree with everything you said except I would put #5 and #6 early in the list since the rest of the things will probably make all the patches need a lot of work, while they could probably be quite easily applied presently. I could be wrong though, just a thought.
Cheers, Matthew Brush
On 11-10-02 09:15 PM, Lex Trotman wrote:
Hi All,
Now we have 0.21 released I thought it was worthwhile looking at the path ahead, and since we have the possibility of some quite significant changes, maybe starting a plan of attack so that not too much effort is wasted.
The big things I see right now that have had some work are:
- change to DVCS and hosting, and possible changes to process that
forces/enables (to my mind the process issues are more important than the DVCS itself)
change to Glade 3 (entails GTK change)
support for GTK3 (needs above and might entail a further GTK change)
support for plugins in non-C, non-compiled languages (as full
plugins, and the VM/interpretor as a plugin itself so core doesn't need to be changed to add more languages)
session support (has been sitting in a branch for a while)
patches in the queue (some are getting a bit old)
bugfixes
call it 1.0
roughly from the most disruptive to least disruptive.
Then there are all the bright new things that will inevitably come up :)
My main suggestion is that it would be best to do the change to the VCS first, then it won't disrupt the other things. And get the process bedded down (stable branch, develop branch, version branches ...) and call that 1.0.
And then other disruptive things can then be done in repository forks so they don't get too much in each others way.
Beyond that its up to individuals which they work on and when, Geany is an open source project after all.
So I suggest that we decide DVCS and host (Git, Github?) and follow the recipe developed in the ML as soon as possible. And then announce the change, and the new processes.
Cheers Lex _______________________________________________ Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
On 3 October 2011 15:37, Matthew Brush mbrush@codebrainz.ca wrote:
Hi Lex,
Agree with everything you said except I would put #5 and #6 early in the list since the rest of the things will probably make all the patches need a lot of work, while they could probably be quite easily applied presently. I could be wrong though, just a thought.
Hi Matthew,
Please note the list isn't in order of doing things, its in order from most disruptive to least disruptive.
It isn't in order of doing things because I was thinking that after the DVCS change some of these can be done in parallel. So for instance things like little patches can be installed in the main develop branch whilst Glade 3/GTK3 can be in another branch. I'm sure the two groups can communicate so that patches that use UI things can be pre-applied, post-applied or merged as appropriate.
Bigger things like SM branch need looking at sure.
And although last (as least disruptive) 1.0 should be done now.
Cheers Lex
On Mon, 3 Oct 2011 15:15:09 +1100 Lex Trotman elextr@gmail.com wrote:
Hi All,
Now we have 0.21 released I thought it was worthwhile looking at the path ahead, and since we have the possibility of some quite significant changes, maybe starting a plan of attack so that not too much effort is wasted.
The big things I see right now that have had some work are:
- change to DVCS and hosting, and possible changes to process that
forces/enables (to my mind the process issues are more important than the DVCS itself)
change to Glade 3 (entails GTK change)
support for GTK3 (needs above and might entail a further GTK
change)
- support for plugins in non-C, non-compiled languages (as full
plugins, and the VM/interpretor as a plugin itself so core doesn't need to be changed to add more languages)
session support (has been sitting in a branch for a while)
patches in the queue (some are getting a bit old)
bugfixes
call it 1.0
In general I'm fine with this list as goals (discussing details would be the wrong place here), but would call it 0.9x with this changes on next release as changes are to big to become a 1.0 directly (to keep understanding of a 1.0 which have been posted on this list bevor)
Cheers, Frank
[...]
In general I'm fine with this list as goals (discussing details would be the wrong place here), but would call it 0.9x with this changes on next release as changes are to big to become a 1.0 directly (to keep understanding of a 1.0 which have been posted on this list bevor)
Hi Frank, can you point to that? On the doodle noone voted for 0.9.
Cheers Lex
On Mon, 3 Oct 2011 20:04:28 +1100 Lex Trotman elextr@gmail.com wrote:
[...]
In general I'm fine with this list as goals (discussing details would be the wrong place here), but would call it 0.9x with this changes on next release as changes are to big to become a 1.0 directly (to keep understanding of a 1.0 which have been posted on this list bevor)
Hi Frank, can you point to that? On the doodle noone voted for 0.9.
The question of doodle was upcoming release which was 0.21 now.
I think the changes you listed, which all make sense taking the general opinion of mailing list, but they are IMHO to big to put all in one release and make it stable within the same one.
Cheers, Frank
On 3 October 2011 20:34, Frank Lanitz frank@frank.uvena.de wrote:
On Mon, 3 Oct 2011 20:04:28 +1100 Lex Trotman elextr@gmail.com wrote:
[...]
In general I'm fine with this list as goals (discussing details would be the wrong place here), but would call it 0.9x with this changes on next release as changes are to big to become a 1.0 directly (to keep understanding of a 1.0 which have been posted on this list bevor)
Hi Frank, can you point to that? On the doodle noone voted for 0.9.
The question of doodle was upcoming release which was 0.21 now.
Ok.
I was asking the question above since you appeared to suggest that there had already been a discussion on how a new version series should work, but I don't remember it, so I was asking for a reminder.
I think the changes you listed, which all make sense taking the general opinion of mailing list, but they are IMHO to big to put all in one release and make it stable within the same one.
Big new changes are actually better to go in a new version series.
I'm guessing from your proposal of 0.9 that you want to follow the GTK method, odd point releases are unstable and even ones stable.
But I don't think that fits with Geany which has a looooong release cycle and tests from the repository rather than making test releases, release candidates etc. Of course we could release more often but I don't see the point of doing that just for unstable releases. If its unstable we shouldn't release it.
And if we are to release more often then we better ask Colomban since he has to do the work. :)
I suggest instead we have VCS branches for the stable series and the unstable one as well as feature branches. This is part of the process I was talking about in item 1 of the OP.
So I am suggesting that the next stable release is 1.0 and based on past performance we won't be releasing it until its stable.
Cheers Lex
PS as usual the most discussion is on the least important thing on the list, but thats human :)
On Mon, 3 Oct 2011 21:05:45 +1100, Lex wrote:
Heyho,
Big new changes are actually better to go in a new version series.
I'm guessing from your proposal of 0.9 that you want to follow the GTK method, odd point releases are unstable and even ones stable.
But I don't think that fits with Geany which has a looooong release cycle and tests from the repository rather than making test releases, release candidates etc. Of course we could release more often but I don't see the point of doing that just for unstable releases. If its unstable we shouldn't release it.
Full ACK (seldom enough that Lex and me agree so much on a topic :D). I also don't think 0.9x versions make much sense. Geany didn't have much beta releases at all in the past.
Also, I guess that most of Lex' list of things to do won't happen all in one single release which would need betas and stuff. I think it's more probable, that this would be an ongoing process and as such, subsequent releases as before would perfectly fit (also to not stretch the release cycle even more). And independently of the version number, hell, it's just a number.
Regards, Enrico
On 11-10-03 02:34 AM, Frank Lanitz wrote:
I think the changes you listed, which all make sense taking the general opinion of mailing list, but they are IMHO to big to put all in one release and make it stable within the same one.
FWIW, a lot of the stuff in the list is already sitting around waiting right now (GtkBuilder, Gtk3, SM, patch tracker patches, etc). Unless Geany has some committment to a scheduled release cycle, it wouldn't make sense to let all of that stuff sit around for a whole other release.
My $0.02 cents.
Cheers, Matthew Brush
On Mon, 03 Oct 2011 07:42:57 -0700 Matthew Brush mbrush@codebrainz.ca wrote:
On 11-10-03 02:34 AM, Frank Lanitz wrote:
I think the changes you listed, which all make sense taking the general opinion of mailing list, but they are IMHO to big to put all in one release and make it stable within the same one.
FWIW, a lot of the stuff in the list is already sitting around waiting right now (GtkBuilder, Gtk3, SM, patch tracker patches, etc). Unless Geany has some committment to a scheduled release cycle, it wouldn't make sense to let all of that stuff sit around for a whole other release.
OK. fine with me. I don't fight for 0.9x or something. It was just some kind of compromise for these, which are thinking 1.0 is something special. Given that most of them is already there we should check to have it in as soon as possible. I suggest to start with sm-branch.
Cheers, Frank
Le 03/10/2011 06:15, Lex Trotman a écrit :
Hi All,
Now we have 0.21 released I thought it was worthwhile looking at the path ahead, and since we have the possibility of some quite significant changes, maybe starting a plan of attack so that not too much effort is wasted.
The big things I see right now that have had some work are:
- change to DVCS and hosting, and possible changes to process that
forces/enables (to my mind the process issues are more important than the DVCS itself)
Yep -- though I think I'm missing something ti your sentence... I don't get the meaning of "and possible changes to process that forces/enables"
change to Glade 3 (entails GTK change)
support for GTK3 (needs above and might entail a further GTK change)
support for plugins in non-C, non-compiled languages (as full
plugins, and the VM/interpretor as a plugin itself so core doesn't need to be changed to add more languages)
session support (has been sitting in a branch for a while)
patches in the queue (some are getting a bit old)
bugfixes
Seems reasonable as future plans, not sure all would fit in a single release... well, we'll see how fast things goes anyway :)
- call it 1.0
Or 1.22, it's what is in SVN now.
roughly from the most disruptive to least disruptive.
Then there are all the bright new things that will inevitably come up :)
My main suggestion is that it would be best to do the change to the VCS first, then it won't disrupt the other things. And get the process bedded down (stable branch, develop branch, version branches ...) and call that 1.0.
Agreed with the strong branching scheme, http://nvie.com/posts/a-successful-git-branching-model/ feels good to me.
And then other disruptive things can then be done in repository forks so they don't get too much in each others way.
And/or feature-branches ;)
Beyond that its up to individuals which they work on and when, Geany is an open source project after all.
So I suggest that we decide DVCS and host (Git, Github?) and follow the recipe developed in the ML as soon as possible. And then announce the change, and the new processes.
Agreed.
Cheers, Colomban
On Mon, Oct 3, 2011 at 17:29, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 03/10/2011 06:15, Lex Trotman a écrit :
Hi All,
Now we have 0.21 released I thought it was worthwhile looking at the path ahead, and since we have the possibility of some quite significant changes, maybe starting a plan of attack so that not too much effort is wasted.
The big things I see right now that have had some work are:
- change to DVCS and hosting, and possible changes to process that
forces/enables (to my mind the process issues are more important than the DVCS itself)
Yep -- though I think I'm missing something ti your sentence... I don't get the meaning of "and possible changes to process that forces/enables"
change to Glade 3 (entails GTK change)
support for GTK3 (needs above and might entail a further GTK change)
support for plugins in non-C, non-compiled languages (as full
plugins, and the VM/interpretor as a plugin itself so core doesn't need to be changed to add more languages)
session support (has been sitting in a branch for a while)
patches in the queue (some are getting a bit old)
bugfixes
Seems reasonable as future plans, not sure all would fit in a single release... well, we'll see how fast things goes anyway :)
- call it 1.0
Or 1.22, it's what is in SVN now.
roughly from the most disruptive to least disruptive.
Then there are all the bright new things that will inevitably come up :)
My main suggestion is that it would be best to do the change to the VCS first, then it won't disrupt the other things. And get the process bedded down (stable branch, develop branch, version branches ...) and call that 1.0.
Agreed with the strong branching scheme, http://nvie.com/posts/a-successful-git-branching-model/ feels good to me.
I just went through the blog post and I must say I disagree with more things than I agree:
1. The split between master and develop is completely unnecessary. I don't see a reason why there should be a separate branch for releases (i.e. commits with tags). The post says that a merge to master is a release by definition. I prefer to do things the way everyone else does them - a commit with a tag is a release by definition. Moreover, everyone expects master is the trunk so I can imagine people will be really confused when they clone a repository and build Geany from sources because master in the above model is a dead space between releases.
2. I agree with non-fast-forward merges of feature branches. These branches however have to be real feature branches where work concentrates on implementing a single feature (e.g. GTK 3 support). For instance I have a branch for_review with random bugfixes and minor features which shouldn't be treated as a feature branch and which can even be rebased on top of master (If you have a look at GTK, you see only a small number of merges - with bugfix-like commits there's very small danger that someone else bases work on them.)
3. I wouldn't make release branches before the actual release - I think having releases directly on master is just fine. This means some slowdown in development but individual developers will have their feature branches where they can continue working and which will be merged to master after the release anyway. Geany isn't a project with such a wild development it should cause any trouble. Maintenance branch for a dot release can be created immediately after the release commit before post-release version increment.
4. Hotfix branches: if a fix is a single commit, it can be directly applied to master and cherry-picked to maintenance branch. If the fix is more of a feature-branch nature, the feature branch for the fix can be created and once finished, it can be merged both to master and to the maintenance branch.
This means the workflow I suggest is very similar to the present workflow; actually I believe it's the workflow used by most projects and the most common-sense one. I'm afraid I'd get quickly lost in the workflow suggested by the blog post and I don't see real benefit for Geany with such a workflow.
Cheers, Jiri
Le 03/10/2011 18:20, Jiří Techet a écrit :
On Mon, Oct 3, 2011 at 17:29, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 03/10/2011 06:15, Lex Trotman a écrit :
[...]
Agreed with the strong branching scheme, http://nvie.com/posts/a-successful-git-branching-model/ feels good to me.
I just went through the blog post and I must say I disagree with more things than I agree:
- The split between master and develop is completely unnecessary. I
don't see a reason why there should be a separate branch for releases (i.e. commits with tags). The post says that a merge to master is a release by definition. I prefer to do things the way everyone else does them - a commit with a tag is a release by definition. Moreover, everyone expects master is the trunk so I can imagine people will be really confused when they clone a repository and build Geany from sources because master in the above model is a dead space between releases.
Agreed, totally. It's not like Git is expected to be the primary source for people wanting the release, in which case making it the default would maybe make sense.
- I agree with non-fast-forward merges of feature branches. These
branches however have to be real feature branches where work concentrates on implementing a single feature (e.g. GTK 3 support). For instance I have a branch for_review with random bugfixes and minor features which shouldn't be treated as a feature branch and which can even be rebased on top of master (If you have a look at GTK, you see only a small number of merges - with bugfix-like commits there's very small danger that someone else bases work on them.)
Yeah, agreed too. What I like in the blog post's workflow is that *every* single feature gets its own incubation branch, not only "big" ones. This cleans up "master" state, and makes reading the history easier.
- I wouldn't make release branches before the actual release - I
think having releases directly on master is just fine. This means some slowdown in development but individual developers will have their feature branches where they can continue working and which will be merged to master after the release anyway. Geany isn't a project with such a wild development it should cause any trouble. Maintenance branch for a dot release can be created immediately after the release commit before post-release version increment.
Not completely sure. Actually during 0.21's freeze, Nick created the unstable branch and worked on it. OK, with a DVCS he could've created a local one (I do have one myself) and rebased it later, but OTOH, it prevents his changes from being seen by others.
But one can also argue that if the development branch isn't the release, the release don't get as much attention as it should...
So I don't have a strong opinion on this, both seems OK to me, yours is more wide spread.
- Hotfix branches: if a fix is a single commit, it can be directly
applied to master and cherry-picked to maintenance branch. If the fix is more of a feature-branch nature, the feature branch for the fix can be created and once finished, it can be merged both to master and to the maintenance branch.
Agreed.
This means the workflow I suggest is very similar to the present workflow; actually I believe it's the workflow used by most projects and the most common-sense one. I'm afraid I'd get quickly lost in the workflow suggested by the blog post and I don't see real benefit for Geany with such a workflow.
Actually, I agree with barely all you points, but the difference seems to be I don't see this as being so different than the blog's post -- maybe because I basically read it as "ideas" rather than bible... my bad for not having been more careful when I said it, thanks to you for having reacted and argued :)
Basically the idea I like is that *every* feature incubates in its branch, not only "big" ones.
Anyway we'd have to write a hacking doc on the way to use the repo, so we can amend it the way we want :)
Cheers, Colomban
On Mon, 03 Oct 2011 18:52:17 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
- I agree with non-fast-forward merges of feature branches. These
branches however have to be real feature branches where work concentrates on implementing a single feature (e.g. GTK 3 support). For instance I have a branch for_review with random bugfixes and minor features which shouldn't be treated as a feature branch and which can even be rebased on top of master (If you have a look at GTK, you see only a small number of merges - with bugfix-like commits there's very small danger that someone else bases work on them.)
Yeah, agreed too. What I like in the blog post's workflow is that *every* single feature gets its own incubation branch, not only "big" ones. This cleans up "master" state, and makes reading the history easier.
+1
Cheers, Frank
On Mon, Oct 3, 2011 at 18:52, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 03/10/2011 18:20, Jiří Techet a écrit :
On Mon, Oct 3, 2011 at 17:29, Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 03/10/2011 06:15, Lex Trotman a écrit :
[...]
Agreed with the strong branching scheme, http://nvie.com/posts/a-successful-git-branching-model/ feels good to me.
I just went through the blog post and I must say I disagree with more things than I agree:
- The split between master and develop is completely unnecessary. I
don't see a reason why there should be a separate branch for releases (i.e. commits with tags). The post says that a merge to master is a release by definition. I prefer to do things the way everyone else does them - a commit with a tag is a release by definition. Moreover, everyone expects master is the trunk so I can imagine people will be really confused when they clone a repository and build Geany from sources because master in the above model is a dead space between releases.
Agreed, totally. It's not like Git is expected to be the primary source for people wanting the release, in which case making it the default would maybe make sense.
- I agree with non-fast-forward merges of feature branches. These
branches however have to be real feature branches where work concentrates on implementing a single feature (e.g. GTK 3 support). For instance I have a branch for_review with random bugfixes and minor features which shouldn't be treated as a feature branch and which can even be rebased on top of master (If you have a look at GTK, you see only a small number of merges - with bugfix-like commits there's very small danger that someone else bases work on them.)
Yeah, agreed too. What I like in the blog post's workflow is that *every* single feature gets its own incubation branch, not only "big" ones. This cleans up "master" state, and makes reading the history easier.
Even in the case of single-commit features? I completely agree with more-than-one-commit features because otherwise you don't know where the feature implementation starts and ends but having it for minor one-commit features seems like overkill to me.
- I wouldn't make release branches before the actual release - I
think having releases directly on master is just fine. This means some slowdown in development but individual developers will have their feature branches where they can continue working and which will be merged to master after the release anyway. Geany isn't a project with such a wild development it should cause any trouble. Maintenance branch for a dot release can be created immediately after the release commit before post-release version increment.
Not completely sure. Actually during 0.21's freeze, Nick created the unstable branch and worked on it. OK, with a DVCS he could've created a local one (I do have one myself) and rebased it later, but OTOH, it prevents his changes from being seen by others.
But one can also argue that if the development branch isn't the release, the release don't get as much attention as it should...
So I don't have a strong opinion on this, both seems OK to me, yours is more wide spread.
I'm not against this idea completely, I just don't feel Geany needs it. If you branch before release it adds some overhead because many commits will go both to the release branch and to master. Anyway, new release is far away so there's plenty of time to decide what's best for Geany meanwhile.
Cheers, Jiri
On Mon, 3 Oct 2011 19:16:09 +0200 Jiří Techet techet@gmail.com wrote:
- I agree with non-fast-forward merges of feature branches. These
branches however have to be real feature branches where work concentrates on implementing a single feature (e.g. GTK 3 support). For instance I have a branch for_review with random bugfixes and minor features which shouldn't be treated as a feature branch and which can even be rebased on top of master (If you have a look at GTK, you see only a small number of merges - with bugfix-like commits there's very small danger that someone else bases work on them.)
Yeah, agreed too. What I like in the blog post's workflow is that *every* single feature gets its own incubation branch, not only "big" ones. This cleans up "master" state, and makes reading the history easier.
Even in the case of single-commit features? I completely agree with more-than-one-commit features because otherwise you don't know where the feature implementation starts and ends but having it for minor one-commit features seems like overkill to me.
Its hard to say. I would say if its really, really, really only just one commit, there is no need to build up a branch. But if there is a chance of a second one ... might be useful. and git checkout -b // git push origin :<branch> is a fast thing
I'm not against this idea completely, I just don't feel Geany needs it. If you branch before release it adds some overhead because many commits will go both to the release branch and to master. Anyway, new release is far away so there's plenty of time to decide what's best for Geany meanwhile.
;) I agree.
Cheers, Frank
Le 03/10/2011 19:20, Frank Lanitz a écrit :
On Mon, 3 Oct 2011 19:16:09 +0200 Jiří Techet techet@gmail.com wrote:
- I agree with non-fast-forward merges of feature branches. These
branches however have to be real feature branches where work concentrates on implementing a single feature (e.g. GTK 3 support). For instance I have a branch for_review with random bugfixes and minor features which shouldn't be treated as a feature branch and which can even be rebased on top of master (If you have a look at GTK, you see only a small number of merges - with bugfix-like commits there's very small danger that someone else bases work on them.)
Yeah, agreed too. What I like in the blog post's workflow is that *every* single feature gets its own incubation branch, not only "big" ones. This cleans up "master" state, and makes reading the history easier.
Even in the case of single-commit features? I completely agree with more-than-one-commit features because otherwise you don't know where the feature implementation starts and ends but having it for minor one-commit features seems like overkill to me.
Its hard to say. I would say if its really, really, really only just one commit, there is no need to build up a branch. But if there is a chance of a second one ... might be useful. and git checkout -b // git push origin :<branch> is a fast thing
Agreed, not much to add. And the push isn't even necessary (or recommended for small ones?), one can create a release branch and only push post-merge.
I'm not against this idea completely, I just don't feel Geany needs it. If you branch before release it adds some overhead because many commits will go both to the release branch and to master. Anyway, new release is far away so there's plenty of time to decide what's best for Geany meanwhile.
;) I agree.
True, and agreed too, it's not necessarily important to decide yet -- and if we don't, we're most likely to not have a pre-release release branch ^^
Cheers, Colomban
On Mon, 03 Oct 2011 19:27:16 +0200 Colomban Wendling lists.ban@herbesfolles.org wrote:
Le 03/10/2011 19:20, Frank Lanitz a écrit :
On Mon, 3 Oct 2011 19:16:09 +0200 Jiří Techet techet@gmail.com wrote:
- I agree with non-fast-forward merges of feature branches.
These branches however have to be real feature branches where work concentrates on implementing a single feature (e.g. GTK 3 support). For instance I have a branch for_review with random bugfixes and minor features which shouldn't be treated as a feature branch and which can even be rebased on top of master (If you have a look at GTK, you see only a small number of merges - with bugfix-like commits there's very small danger that someone else bases work on them.)
Yeah, agreed too. What I like in the blog post's workflow is that *every* single feature gets its own incubation branch, not only "big" ones. This cleans up "master" state, and makes reading the history easier.
Even in the case of single-commit features? I completely agree with more-than-one-commit features because otherwise you don't know where the feature implementation starts and ends but having it for minor one-commit features seems like overkill to me.
Its hard to say. I would say if its really, really, really only just one commit, there is no need to build up a branch. But if there is a chance of a second one ... might be useful. and git checkout -b // git push origin :<branch> is a fast thing
Agreed, not much to add. And the push isn't even necessary (or recommended for small ones?), one can create a release branch and only push post-merge.
Yep. The push example was for the case you needed to push the branch.
Cheers, Frank
[...]
Even in the case of single-commit features? I completely agree with more-than-one-commit features because otherwise you don't know where the feature implementation starts and ends but having it for minor one-commit features seems like overkill to me.
Lets just use commonsense and judgement, it won't be right every time but often enough to be useful.
[...]
I'm not against this idea completely, I just don't feel Geany needs it. If you branch before release it adds some overhead because many commits will go both to the release branch and to master. Anyway, new release is far away so there's plenty of time to decide what's best for Geany meanwhile.
Yes, and when closer can have some practice releases.
Cheers Lex
On Tue, Oct 4, 2011 at 02:19, Lex Trotman elextr@gmail.com wrote:
[...]
Even in the case of single-commit features? I completely agree with more-than-one-commit features because otherwise you don't know where the feature implementation starts and ends but having it for minor one-commit features seems like overkill to me.
Lets just use commonsense and judgement, it won't be right every time but often enough to be useful.
Yes exactly. It was the blog post from which I had a feeling that "everything has to be done this and only this way" and that's why I tried to come up with some examples where it might not work. If the rules aren't carved into stone and allow some flexibility then I'm completely fine with it.
Cheers,
Jiri
On Mon, 3 Oct 2011 18:20:35 +0200 Jiří Techet techet@gmail.com wrote:
- The split between master and develop is completely unnecessary. I
don't see a reason why there should be a separate branch for releases (i.e. commits with tags). The post says that a merge to master is a release by definition. I prefer to do things the way everyone else does them - a commit with a tag is a release by definition. Moreover, everyone expects master is the trunk so I can imagine people will be really confused when they clone a repository and build Geany from sources because master in the above model is a dead space between releases.
Here I need to disagree. I think its a good idea to have a separate releases branch. Its not a big effort to maintain it and will allow users to build releases direct from git more easily.
- I wouldn't make release branches before the actual release - I
think having releases directly on master is just fine. This means some slowdown in development but individual developers will have their feature branches where they can continue working and which will be merged to master after the release anyway. Geany isn't a project with such a wild development it should cause any trouble. Maintenance branch for a dot release can be created immediately after the release commit before post-release version increment.
I agree. There is no real need to have release branches always and in every cases. They can be created on demand from every parent.
- Hotfix branches: if a fix is a single commit, it can be directly
applied to master and cherry-picked to maintenance branch. If the fix is more of a feature-branch nature, the feature branch for the fix can be created and once finished, it can be merged both to master and to the maintenance branch.
Sounds reasonable.
Cheers, Frank
On Mon, Oct 3, 2011 at 19:00, Frank Lanitz frank@frank.uvena.de wrote:
On Mon, 3 Oct 2011 18:20:35 +0200 Jiří Techet techet@gmail.com wrote:
- The split between master and develop is completely unnecessary. I
don't see a reason why there should be a separate branch for releases (i.e. commits with tags). The post says that a merge to master is a release by definition. I prefer to do things the way everyone else does them - a commit with a tag is a release by definition. Moreover, everyone expects master is the trunk so I can imagine people will be really confused when they clone a repository and build Geany from sources because master in the above model is a dead space between releases.
Here I need to disagree. I think its a good idea to have a separate releases branch. Its not a big effort to maintain it and will allow users to build releases direct from git more easily.
git checkout RELEASE_TAG ./configure; make; sudo make install
It's not that difficult.
I'm not completely against the releases branch, but I'm strongly against this to be "master". In addition I'm not sure how to handle situations when you want to release say 0.22 and few days after the last maintenance release of 0.21. e.g. 0.21.3 - those two will conflict badly.
Cheers, Jiri
On Mon, 3 Oct 2011 19:24:40 +0200 Jiří Techet techet@gmail.com wrote:
On Mon, Oct 3, 2011 at 19:00, Frank Lanitz frank@frank.uvena.de wrote:
On Mon, 3 Oct 2011 18:20:35 +0200 Jiří Techet techet@gmail.com wrote:
- The split between master and develop is completely unnecessary.
I don't see a reason why there should be a separate branch for releases (i.e. commits with tags). The post says that a merge to master is a release by definition. I prefer to do things the way everyone else does them - a commit with a tag is a release by definition. Moreover, everyone expects master is the trunk so I can imagine people will be really confused when they clone a repository and build Geany from sources because master in the above model is a dead space between releases.
Here I need to disagree. I think its a good idea to have a separate releases branch. Its not a big effort to maintain it and will allow users to build releases direct from git more easily.
git checkout RELEASE_TAG ./configure; make; sudo make install
It's not that difficult.
I'm not completely against the releases branch, but I'm strongly against this to be "master". In addition I'm not sure how to handle situations when you want to release say 0.22 and few days after the last maintenance release of 0.21. e.g. 0.21.3 - those two will conflict badly.
Wasn't thinking about to make it as master. But the last point you mentioned is correct. We should really only use tags on master or inside maintenance branches.
Cheers, Frank
[...]
Yep -- though I think I'm missing something ti your sentence... I don't get the meaning of "and possible changes to process that forces/enables"
Apologies for the inelegant language. You said it yourself below :), I meant things like using branches and committing to develop not master etc.
[...]
Seems reasonable as future plans, not sure all would fit in a single release... well, we'll see how fast things goes anyway :)
Sure see how we go, but on Geany's usual release cycle it would be long time to wait if they don't fit this cycle.
- call it 1.0
Or 1.22, it's what is in SVN now.
Ok. Anything to avoid another doodle please :)
[...]>
Agreed with the strong branching scheme, http://nvie.com/posts/a-successful-git-branching-model/ feels good to me.
Agree.
And then other disruptive things can then be done in repository forks so they don't get too much in each others way.
And/or feature-branches ;)
For big changes I'd say start with a fork where the dev and friends can mess around to their hearts content until it seems to work, then make a feature branch as it moves towards usability and you want more people to test and QA it and have it a bit more community controlled and then merge with develop as it is accepted.
Small changes/bugfixes make in a fork until it works and send Colomban a pull request to put it in develop or send him patches.
Cheers Lex