Hi together,
with today's commits [1] the behavior of the gencontent.sh has changed. The script now tries getting the README files from the latest Geany-Plugins release and not from git master anymore.
For you as a plugin maintainer, this now means that you'd need to create a branch exactly named as the tag of the latest release and put changes to README files there as well in case they apply for an already released version of Geany-Plugins. gencontent.sh would look for changes in that branch then and not in master.
In other words: plugins.geany.org now has the content of the README files of the tag 0.21.1. If you like to improve something there, the changes must be made to a branch called 0.21.1 created from the tag.
This should apply to a common work flow when fixing issues in an already released version, so I guess no big deal for anyone of you. Feel free to correct me, if you think I am wrong with this. :)
Any further suggestions or improvements are welcome, feel free to fork the stuff and open pull requests. ;)
Best Regards, Dominic
[1] https://github.com/dmaphy/plugins.geany.org/commits/master
Am Samstag, den 17.12.2011, 17:05 +0100 schrieb Dominic Hopf:
[1] https://github.com/dmaphy/plugins.geany.org/commits/master
The repository has moved to the Geany organisation. New link:
https://github.com/geany/plugins.geany.org/commits/master
Regards, Dominic
On Sat, 17 Dec 2011 18:05:17 +0100, Dominic wrote:
Am Samstag, den 17.12.2011, 17:05 +0100 schrieb Dominic Hopf:
[1] https://github.com/dmaphy/plugins.geany.org/commits/master
The repository has moved to the Geany organisation. New link:
Just for the records, I enabled IRC and email commit messages, the email commit messages are sent to the geany-plugins-commits list.
Regards, Enrico
17.12.2011 20:05, Dominic Hopf пишет:
Hi together,
with today's commits [1] the behavior of the gencontent.sh has changed. The script now tries getting the README files from the latest Geany-Plugins release and not from git master anymore.
For you as a plugin maintainer, this now means that you'd need to create a branch exactly named as the tag of the latest release and put changes to README files there as well in case they apply for an already released version of Geany-Plugins. gencontent.sh would look for changes in that branch then and not in master.
In other words: plugins.geany.org now has the content of the README files of the tag 0.21.1. If you like to improve something there, the changes must be made to a branch called 0.21.1 created from the tag.
This should apply to a common work flow when fixing issues in an already released version, so I guess no big deal for anyone of you. Feel free to correct me, if you think I am wrong with this. :)
Any further suggestions or improvements are welcome, feel free to fork the stuff and open pull requests. ;)
Best Regards, Dominic
[1] https://github.com/dmaphy/plugins.geany.org/commits/master
Geany-devel mailing list Geany-devel@uvena.de https://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
Hi Dominic,
I didn't get clear how to deal with the newly created branch after a bug is fixed in it: push branch to github, merge with master and push master or whatever? Can you pls give some more details.
Regards, Alex
Am Sonntag, den 18.12.2011, 19:17 +0400 schrieb Alexander Petukhov:
Hi Dominic,
I didn't get clear how to deal with the newly created branch after a bug is fixed in it: push branch to github, merge with master and push master or whatever? Can you pls give some more details.
If you are going to fix a bug which is present since 0.21.1, you would create the branch 0.21.1 from the tag, fix your stuff there, and push the branch upstream via `git push -u origin 0.21.1`.
Then you of course also apply the fix to master, separately from the fix for the special version 0.21.1 using the git cherry-pick command:
git checkout master git cherry-pick <commit-id>
Regards, Dominic