Re: [trinity-devel] R14.0.x branch

On Thursday 16 of October 2014 05:14:49 Michele Calgaro wrote: > <snip> > >> 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

>> to maintain. > > Agree in full, as I also said before. We can switch to option 3 at a > later stage if out team grows over time > >> 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 prefer option 2b). The main trunk is the development trunk and so > should keep moving forward any time. When we want to release a new > version (major, minor, maintenance), we branch as described. > >> I understand "nightly-builds" in the sense that their mission is to >> keep at the forefront of the development branch. And I consider it

>> 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,

>> packages for nightly-builds, update 'po' files,... all these

>> 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

>> clones whole git repositories and automation scripts separately for >> each such branch. Anything else would be prone to confusion.

>> this is not necessary. As I mentioned in a previous email, I am

>> 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. > > I understand from Tim's mail that there are limitations on what it > possible to do on the primary nightly-build site and I won't argue > against them since I have no knowledge of the internal mechanisms > involved. It's ok for me if you want to maintain the new branches. > The only thing that is still a little blurry in my mind is this: once > v14.0.0 is release and we create the v14.0.0 branch, the main trunk

> be for v14.1.x. So how are we going to build v14.0.1 when the time

Packages I upload to my PPA on build-farm, where they will build. This corresponds to the links that I sent in the previous mail. From such a PPA Tim then can copy the packages into the official repository - to

mirrors. Now I have it so that the same source packages I'll send to the build-farm and in addition also to my builder => my alternative

where in addition are builds for Wheezy on MIPS and PowerPC.