10 Dec
2014
10 Dec
'14
12:47 a.m.
On Wednesday 10 of December 2014 00:31:09 Timothy Pearson wrote:
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.
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.
Dne čt 4.
prosince 2014 Michele Calgaro napsal(a):
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.
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. 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 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.
Thanks!
Tim
--
Slávek