8 Dec
2014
8 Dec
'14
6:04 p.m.
Dne čt 4. prosince 2014 Michele Calgaro napsal(a):
On 10/16/2014 01:02 PM, Slávek Banko wrote:
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
On Thursday 16 of October 2014 05:14:49 Michele
Calgaro wrote:
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
<snip>
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. 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