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