<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