use git for release/hotfix/... tracking / do not track config.php

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

use git for release/hotfix/... tracking / do not track config.php

Oluf Lorenzen
Hi,

i already asked that some days ago in the irc-channel where i've been asked to
backport it to the mailing list :)

It would be really nice if you would use branches for each release you tag.
That would ease upgrading the files on an productive system as you simply
switch branches from e.g. [release-0.1] to [release-1.0].

I'd suggest reading [1] if some of you want to dig deeper into that (there are
also bash-completion-scripts :)).

Another thing would be to remove the config.php from VCS as there is
an .gitignore-entry for it and only maintain the .example.php (this is really
mixed up, IMO).
Only using one root-.gitignore-file would add some clarity, too.

Regards,
Oluf

[1]: <http://nvie.com/posts/a-successful-git-branching-model/>
--
Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.

Please note that according to the German law on data retention,
information on every electronic information exchange with me is retained
for a period of six months.

Reply | Threaded
Open this post in threaded view
|

Re: use git for release/hotfix/... tracking / do not track config.php

Aldo "xoen" Giambelluca
2010/10/20 Oluf Lorenzen <finkregh at mafia-server.net>:
> It would be really nice if you would use branches for each release you tag.
> That would ease upgrading the files on an productive system as you simply
> switch branches from e.g. [release-0.1] to [release-1.0].
>
> I'd suggest reading [1] if some of you want to dig deeper into that (there are
> also bash-completion-scripts :)).
> [...]
>
> [1]: <http://nvie.com/posts/a-successful-git-branching-model/>

Thanks for the suggestion, I've found the time to read it and it's
really interesting, there are good ideas in it and I suggest Karl and
Robin to read it too (if not yet read it). I would use master for
develpment as usual and a stable branch for releases.

The features branch are already used (more or less).

The release branch where only bugfixing occur is a good idea and it
leave free to continue development in master while releasing.
Author doesn't keep release branches after the relase but maybe it
could be an idea to support older releases (this is an important thing
author doesn't cover).

Also the hotfix branches are a good idea, but there isn't a lot of bug
[2] in the tracking system at the moment :P.


[2]: https://bugs.kde.org/buglist.cgi?query_format=specific&order=relevance+desc&bug_status=__open__&product=owncloud



--
Aldo "xoen" Giambelluca
-.. --- -. .----. - / .--. .- -. .. -.-.

Reply | Threaded
Open this post in threaded view
|

Re: use git for release/hotfix/... tracking / do not track config.php

kees
In reply to this post by Oluf Lorenzen
I was just planning to fix some bugs, but where is the tracking system?

On Sunday 31 October 2010 11:17:13 Oluf Lorenzen wrote:

> > The release branch where only bugfixing occur is a good idea and it
> > leave free to continue development in master while releasing.
> > Author doesn't keep release branches after the relase but maybe it
> > could be an idea to support older releases (this is an important thing
> > author doesn't cover).
>
> Well, just drop the author an email (me at nvie.com) or work on you own branch
> via [1] ;)
>
> > Also the hotfix branches are a good idea, but there isn't a lot of bug
> > [2] in the tracking system at the moment :P.
>
> Another problem seems to be that nobody from the project works on the
> existant bugs. E.g. #250518 could be closed/wontfix or whatever is
> apropriate there ;)
>
>
> [1]: <http://github.com/nvie/gitflow>

Reply | Threaded
Open this post in threaded view
|

Re: use git for release/hotfix/... tracking / do not track config.php

Oluf Lorenzen
In reply to this post by Aldo "xoen" Giambelluca
> The release branch where only bugfixing occur is a good idea and it
> leave free to continue development in master while releasing.
> Author doesn't keep release branches after the relase but maybe it
> could be an idea to support older releases (this is an important thing
> author doesn't cover).

Well, just drop the author an email (me at nvie.com) or work on you own branch
via [1] ;)

> Also the hotfix branches are a good idea, but there isn't a lot of bug
> [2] in the tracking system at the moment :P.

Another problem seems to be that nobody from the project works on the existant
bugs. E.g. #250518 could be closed/wontfix or whatever is apropriate there ;)


[1]: <http://github.com/nvie/gitflow>
--
Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge
jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.

Please note that according to the German law on data retention,
information on every electronic information exchange with me is retained
for a period of six months.

Reply | Threaded
Open this post in threaded view
|

Re: use git for release/hotfix/... tracking / do not track config.php

Robin Appelman
In reply to this post by kees
It's on bugs.kde.org

https://bugs.kde.org/buglist.cgi?quicksearch=owncloud

On Sun, Oct 31, 2010 at 09:54, kees
<itissohardtothinkofagoodemail at gmail.com> wrote:

> I was just planning to fix some bugs, but where is the tracking system?
>
> On Sunday 31 October 2010 11:17:13 Oluf Lorenzen wrote:
>> > The release branch where only bugfixing occur is a good idea and it
>> > leave free to continue development in master while releasing.
>> > Author doesn't keep release branches after the relase but maybe it
>> > could be an idea to support older releases (this is an important thing
>> > author doesn't cover).
>>
>> Well, just drop the author an email (me at nvie.com) or work on you own branch
>> via [1] ;)
>>
>> > Also the hotfix branches are a good idea, but there isn't a lot of bug
>> > [2] in the tracking system at the moment :P.
>>
>> Another problem seems to be that nobody from the project works on the
>> existant bugs. E.g. #250518 could be closed/wontfix or whatever is
>> apropriate there ;)
>>
>>
>> [1]: <http://github.com/nvie/gitflow>
> _______________________________________________
> Owncloud mailing list
> Owncloud at kde.org
> https://mail.kde.org/mailman/listinfo/owncloud
>