15 Oct
2014
15 Oct
'14
2:38 p.m.
> In the worst case, I think it would be a good idea
to at least create a
> temporary "development branch" where patches can be pushed while the
> hard freeze is in place for v14.0.0. After v14.0.0 is released, the
> changes made can be merged into the main trunk.
>
I am afraid that with the branches is the same as with
the tags - after
creating on the server branch synchronizes to users, but after remove on the
server users will have to worry about removing branch == all the users
themselves. This is not good. Therefore, I am not a fan of temporary branches
on the server.
The temporary branch would be just for us developers, not for the main users, to be able
to comtinue development. And given that we are just 5 people, I tihnk it would be
managable.
Nevertheless I would still prefer to branch as you described in option 2 earlier today.
Tim, I don't know how the build farm works internally, but perhaps the following idea
could be useful.
- create a file with the list of all modules that should be built. For each module
indicate whether to build against the current source in the master branch or against a
particular GIT hash in a particular branch.
- modify the build process to read the file above and checkout the proper branch and
commit for each module, then build the module
In this way, when we want to build "standard" nightly build packages, we just
say to build againast the current source and master branch
When we want to build a specific image (for example RC1, RC2, v14.0.0 and later versions)
we use a different index file which contains the correct information for such build. This
would also to build different "versions" any time we want.
Just an idea, as I said I do not know the internal mechanisms of the build farm.
Cheers
Michele