Avery Pennarun <apenwarr@xxxxxxxxx> writes:
> On Mon, Apr 5, 2010 at 10:34 AM, Stephen Kelly <steveire@xxxxxxxxx> wrote:
>> I want to make a 0.1 release, so that would mean creating a 0.1 branch and
>> updating files contained in the branch such as the README file and the CMake
>> files and the api documentation to report version 0.1.0, and creating the
>> 0.1.0 tag. The next tag on that branch would be 0.1.1 etc. Simultaneously,
>> the version number in those files is changes to 0.2.0 in the master branch.
>>
>> However, now I have changes in my maintenance branch (0.1) which should not
>> be merged into master (that is, the commits which change the version
>> number).
>>
>> How are you supposed to handle that with git? Simply merge and resolve the
>> conflict on master by keeping its version number? Am I missing some other
>> way of doing it here?
>
> I've used that method. it works fine, and the conflicts are only
> whenever the maintenance branch version number changes, which is very
> rare (and easy to see).
You can even make sure it _never_ happens, by making a one-commit
release branch which changes the version number for each release. This
one-commit is never merged in anything:
0.1 0.2
| |
v v
--o--o--o--o--o--o--o--o---o--o--o <--- master branch
\ /
o--o--o--o--o--o--o--o--- ... <--- maintainance branch
\ \
o <- 0.1.1 o <- 0.1.2
Here, the maintainance branch never changes the version number in
README & friends.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html