On Wednesday 15 of October 2014 06:23:33 Michele Calgaro wrote: > On 2014/10/15 12:12 PM, Sl�vek Banko wrote: > > On Wednesday 15 of October 2014 04:30:15 Michele Calgaro wrote: > >> 2) about freezing, development and v14.0.x > >> Tim, is it possible to create a GIT branch for v14.0.0 so that we can > >> keep pushing patches *not to be in v14.0.0* to the main trunk? The main > >> question here is actually "how are we going to maintain the v14.0.x > >> branch when v14.0.0 has been release and the main trunk will be for > >> v14.1.0"? > >> > >> > >> Cheers > >> Michele > > > > This raises the question of the use of branches in the further > > development. There are several options: > > > > 1) One extreme - do not use branches at all. > > > > = R14.0.0 === R14.0.1 === R14.0.2 === R14.1.0 === R14.1.1 === R14.2.0 === > > R15.0.0 > > > > I assume that the experience from the maintenance branch > > v3.5.13-sru excludes this option. > > > > > > 2) Create a branches for the minor/"feature" revisions: > > > > __R14.1.1___R14.1.2___R14.1.3 > > / > > / __R15.0.1 > > / / > > = R14.0.0 === R14.1.0 === R14.2.0 === R15.0.0 === R15.1.0 > > \ \ > > \ \__R14.2.1___R14.2.2 > > \ > > \__R14.0.1___R14.0.2___R14.0.3 > > > > > > 3) Create a branches for the major/"abi" revisions and > > 'sub' branches for minor/"feature" revisions: > > > > ___R15.1.0___R15.1.1 > > / > > /__R15.0.1___R15.0.2 > > / > > = R14.0.0 ====== R15.0.0 ====== R16.0.0 > > \ > > \__R14.0.1___R14.0.2___R14.0.3 > > \ > > \__R14.1.0___R14.1.1___R14.1.2 > > \ > > \__R14.2.0___R14.2.1 > > > > > > Based on the existing experience for me seems optimal option 2). In any > > case, I suggest to not create a 'tags' for rc versions - solely for the > > final releases, to avoid unnecessarily large number of tags. > > > > The second question is "when is the time" to create a branch. As I > > mentioned earlier, nightly-builds are designed to build on 'master' > > branch. When we create new branch, then nightly-builds should start > > with version numbers corresponding to the new target version - for > > example, 14.1.0~preXXX. Thus, if a new branch will be created now - > > with RC1, then I assume that this is the moment for me to start > > worry about the preparation of stable-builds in my ppa. > > > > I note: for some time I maintain 'preliminary-stable-builds' on my > > mirror. At the same time I have already prepared PPA to maintain > > 'stable-builds' on the build-farm. That is to say, that I am ready > > to maintain maintanance releases R14.0.x. > > > > What is your opinion - when is the time to create branch and start > > the 'maintanance mode'? > > Hi Slavek, > thanks for spending the time to write such a detail email. It summarizes > very well my thoughts as well. > > Option 3) would be the best choice if we had a clear roadmap for what to > do in the future releases and more developers, since it would allow to > work on v15.0.0, v14.x.y and maintanin v14.0.x at the same time. > Given the amount of resources that we have, I think that option 2) is > the most viable choice. > > Regarding the time of branching, my view is that we should first rework > the nightly-building process to allow to choose which branch to build > from. This is in view of future builds of v14.0.x when the main trunk > will be on v14.1.0. > If we change the building process as explained, then the time of branch > is "now". We create a branch for v14.0.x, which will contain v14.0.0 and > all subsequent maintenance releases. Then we create a sub-branch v14.0.0 > that will contain only v14.0.0. > I do not see the need to use tags for RC1, RC2 if we use this method. > In pictures: > > == Main trunk --> work can continue for v14.1.0 > \ > \__R14.0.x --> work can continue for v14.0.x, > \ patches can be pushed any time but will > \ not go into v14.0.0 > \ > \__R14.0.0 --> branch for v14.0.0. When we want to > build RC1, instruct the nightly-build > process to build from here. Later do > the same for RC2 and for the final > v14.0.0 release. > > > At later stage, we will create sub branches for v14.0.1, v14.0.2 and so > on. Given that branches in GIT are cheap and that changes can easily be > merged from trunk or from the R14.0.x sub-trunk, this should be a > reasonable working solution. > Plus if one day we decide to do so, we can easily switch to option 3: we > just create the v14.x.y sub branch. > > Just my 2 cents. > > Cheers > Michele > Option 3) would have more weight if our team was larger and had also been detailed roadmap of the upcoming development. In our situation, however, I believe that for our small team would present higher demands to maintain. For option 2) I had the intention of following sub-options: 2a) release major version from 'master' branch: __R14.1.1___R14.1.2___R14.1.3 / / __R15.0.1 / / = R14.0.0 === R14.1.0 === R14.2.0 === R15.0.0 === R15.1.0 \ \ \ \__R14.2.1___R14.2.2 \ \__R14.0.1___R14.0.2___R14.0.3 2b) release all versions from 'maintanance' branches: __R14.1.0___R14.1.1___R14.1.2 / / __R15.0.0 / / = R14.0.x === R14.1.x === R14.2.x === R15.0.x === R15.1.x \ \ \ \__R14.2.1___R14.2.2 \ \__R14.0.0___R14.0.1___R14.0.2 I understand "nightly-builds" in the sense that their mission is to keep at the forefront of the development branch. And I consider it to be correct. On the primary site is running several automation processes, whose mission is related to the maintenance of the development 'master' branch. For example, automatic updating of the submodules in 'tde' repository, generate page with commits, preparing packages for nightly-builds, update 'po' files,... all these processes need git repository on "constantly same branch". If should be addressed on the primary site also other branches, it would only make sense that on the primary site was simultaneously more clones whole git repositories and automation scripts separately for each such branch. Anything else would be prone to confusion. However, this is not necessary. As I mentioned in a previous email, I am ready to maintain new 'maintanance' branch and provide the necessary automation processes. This way we have successfully verified while working on v3.5.13-sru branch. Incidentally, the corresponding PPA I have already created and updated packages I'll upload soon: https://quickbuild.pearsoncomputing.net/~slavek-banko/+archive/deps-r14/+packages https://quickbuild.pearsoncomputing.net/~slavek-banko/+archive/main-r14/+packages -- Sl�vek