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: Wed, 10 Dec 2014 01:47:44 +0100
On Wednesday 10 of December 2014 00:31:09 Timothy Pearson wrote:
> > 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.
>
> Tags and branches created.  I did not create a branch for the
> tde-packaging repository as I don't think it will be needed; if this
> proves to be wrong in the future it can be easily corrected.
>

Branch on tde-packaging was necessary in v3.5.13.x era and we can assume that 
it will be useful also for R14.0.x. However, it may be created when will be 
ready also packages for other distributions.

I tested that I need to properly fix scripts/create_tarball, because due to 
the initial character in tag name fails sort of tags by version number.

> > By the way, Tim, this will be an opportunity in the official
> > nightly-build switch to using '~' in the version numbers.
>
> Can you elaborate further?  I don't recall a recent discussion on this.
>

Remember to v3.5.13.2 branch: preliminary packages was version 3.5.13.2~preXXX 
and thanks to using the character '~', packages for final version can have 
version number simply 3.5.13.2 == clear final version number.

> Thanks!
>
> Tim
>
-- 
Slávek