trinity-devel@lists.pearsoncomputing.net

Message: previous - next
Month: December 2014

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

From: Slávek Banko <slavek.banko@...>
Date: Mon, 8 Dec 2014 19:04:54 +0100
Dne čt 4. prosince 2014 Michele Calgaro napsal(a):
> On 10/16/2014 01:02 PM, Slávek Banko wrote:
> > 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 demands
> >>> 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 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.
> >>
> >> 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 will
> >> be for v14.1.x. So how are we going to build v14.0.1 when the time for
> >> the first maintenance release comes? Are we going to use your own
> >> builder for this?
> >>
> >> Cheers
> >>     Michele
> >
> > 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 the
> > 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 mirror,
> > where in addition are builds for Wheezy on MIPS and PowerPC.
>
> Tim, Slavek,
> I think it is now time we start thinking about the R14.0.x branch.
> IMO, we can wait until R14.0.0 is released, given that we have waited until
> now. Then we create a R14.0.x branch on the main repo which will be the
> development branch for any R14.0.x maintenance release. The trunk will
> remain the development branch for R14.1.0.
>
>  From earlier discussions we had some months ago, my understanding is that
> the build farm will continue to build nightly builds based on the main
> development branch, while Slavek's builder will take care of building the
> R14.0.x releases when ready (or perhaps some periodical nightly build as
> well). Is this still correct?
>
> Cheers
>    Michele
>

Yes, I suppose it exactly the same. After tagging v14.0.0 and create branch 
v14.0.x, nightly-builds will continue on 'master' branch to target R14.1.0, 
while my ppa on build-farm as well as my alternate apt repository will 
continue on 'v14.0.x' branch to target R14.0.1.

By the way, Tim, this will be an opportunity in the official nightly-build 
switch to using '~' in the version numbers.

-- 
Slávek