From gambas at ...1...  Sat Jul  1 18:36:31 2017
From: gambas at ...1... (=?UTF-8?Q?Beno=c3=aet_Minisini?=)
Date: Sat, 1 Jul 2017 18:36:31 +0200
Subject: [Gambas-devel] Unit-Tests
In-Reply-To: <bdea99d7-1d69-9aef-c6c4-854f7f1a09c2@...757...>
References: <bdea99d7-1d69-9aef-c6c4-854f7f1a09c2@...757...>
Message-ID: <b06df866-3081-f3f9-6ae2-5963a1e192b7@...1...>

Le 01/07/2017 ? 11:40, Christof Thalhofer a ?crit :
> Hello Beno?t,
> 
> I write you because I got no answer in the dev-ML. Is there any interest
> in integrating the UnitTest to the IDE on your side? Or do you have no
> time, currently?
> 
> If Yes (interest):
> 
> There is a new version on Github (had to do a small fix):
> https://github.com/Deganius/gb.deg.unittest
> 
> To see it work, just load the Project and hit F5.
> 
> But there is a major problem with it:
> 
> It should be able to inspect and test a project "from the outside" and I
> did not find a way to do that.
> 
> 
> Thank you and a nice weekend!
> 
> Christof Thalhofer
> 

I have answered you on the devel mailing-list, I just asked first if it 
was commented in english.

Then your component just have to be put in the subversion repository.

I will mainly check the interface of your component and the names of 
your symbol. I have read your documentation on github, and I'm not sure 
I like them! :-)

I will have some time next week, and I want to release Gambas 3.10. 
Maybe we can put your code in /trunk just after that?

Regards,

-- 
Beno?t Minisini



From taboege at ...176...  Sat Jul  1 21:46:57 2017
From: taboege at ...176... (Tobias Boege)
Date: Sat, 1 Jul 2017 21:46:57 +0200
Subject: [Gambas-devel] Gambas 3.10 - gb.web.feed
Message-ID: <20170701194657.GC568@...756...>

On Sat, 01 Jul 2017, Beno?t Minisini via Gambas-devel wrote:
> I will have some time next week, and I want to release Gambas 3.10.

Hi Benoit,

Gambas 3.10 would include the new gb.web.feed, right? I have some local
changes pending which better be committed before the component is first
included in a stable version.

As I mentioned earlier, I want Date values in RSS to be accompanied by
an RFC822 timezone string, because I want to give the user a way to
specify the timezone string when they create RSS documents (e.g. an RSS
feed of a local newspaper in Germany should not have the timezone of
the US-located server machine where the feed is put together, but the
German timezone relevant to the article).

I need the following:

  1. A way to get the timezone string out of the RFC822 parser in gb.util.
  2. Two functions which convert between RFC822 timezone string and
     a numeric representation (number of seconds from UTC?) I believe
     those functions are already in gb.util, but Private.
  3. An RFC822 timezone string for the local system timezone, as a
     reasonable default when the user gives no timezone.
  4. Functions which convert a (date, timezone) pair, which is to be
     understood as "<date> is in/relative to <timezone>" to another
     timezone.

I think if 1. and 2. are there, I can implement 3. and 4. by myself.
Having 4. would give me a clean conscience, as I intend to store the
timezone inside the component just as an RFC822 timezone string and
let the user handle calculations with timezones if they need it.
Point 4. then gives the user the needed primitives.

Please also look at [1] where I listed some doubts I have about the
current RFC822 functions in gb.util.

Regards,
Tobi

[1] https://sourceforge.net/p/gambas/mailman/message/35810371/

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk



From gambas at ...1...  Sat Jul 22 19:21:44 2017
From: gambas at ...1... (=?UTF-8?Q?Beno=c3=aet_Minisini?=)
Date: Sat, 22 Jul 2017 19:21:44 +0200
Subject: [Gambas-devel] Translation for gambas 3.9.2 Chinease Simplified
In-Reply-To: <CAHktmdE53aH8xdCztEiCCa-vdJqYYGid_9x_6E_8u-wKZM7row@...178...>
References: <CAHktmdE53aH8xdCztEiCCa-vdJqYYGid_9x_6E_8u-wKZM7row@...178...>
Message-ID: <cfa37c2c-6711-cc74-54df-01845e2151e3@...1...>

Le 24/04/2017 ? 06:58, Yizhou He a ?crit :
> Hi,
> 
> Sorry if I post in wrong mail list. Lost all my contact in email after 
> finish graduate school. They take my mail box away. Please let me know 
> where I'm supposed to submit the updated translation file if I post in 
> wrong list.
> 
> 
> Thanks,
> 
> 
> 
> Yizhou He
> 

I have merged your translation in the upcoming 3.10 version.

Otherwise, you can ask me a write access to the subversion repository. 
Then you make and commit your translation directly from the IDE.

Regards,

-- 
Beno?t Minisini



From adrien.prokopowicz at ...176...  Sat Jul 22 20:35:17 2017
From: adrien.prokopowicz at ...176... (Adrien Prokopowicz)
Date: Sat, 22 Jul 2017 20:35:17 +0200
Subject: [Gambas-devel] Gambas to Git(Lab)
Message-ID: <op.y3si830ydlsaci@...102...>

Hello everyone,

In an effort to both switch the Gambas project versioning to Git, and to  
move away
 from Sourceforge, I imported the whole repository to GitLab. You can see  
it here :

https://gitlab.com/prokopyl/gambas

 From what I see, all history, commits, tags and branches have been  
successfully
imported, and authors have been correctly mapped from their Sourceforge  
usernames to
Git full names and emails (the SVN/Git mapping file is attached).

I know there has been some GitHub vs. GitLab debate on the mailing list  
somewhere,
but it didn't seem to have produced anything, so I just picked one.
Since nothing I have done is GitLab-specific (it's just a plain Git  
repository for now),
we can easily use GitHub too.
I personally picked GitLab simply because we can easily retrieve data  
(issues, wiki and such)
 from a generated archive if we ever want to switch, and their integrated  
CI solution
seems less restricted than Travis (but I didn't go that far with it).

For now, all I did was cloning the entire SVN repo on the server that  
hosts the
playground (for its symmetric 100Mbit/s connection :) ), then using  
git-svn to
create a git repo from the clone, and then push it all to GitLab.

I'm currently trying to set up Continuous Integration to generate Ubuntu  
packages, and
maybe for more distributions later (RHEL/CentOS, Debian, ArchLinux, ?).

I know we won't switch to Git right now, I'm at least waiting for 3.10 to  
be released
so everything can calm down. :)
However I would like your feedback : what do you think is needed to make  
Gambas
successfully switch to Git ? (Whichever host we end up choosing).

Regards,
-- 
Adrien Prokopowicz
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: authors.txt
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20170722/5645205e/attachment.txt>

From karl.reinl at ...16...  Sat Jul 22 21:19:54 2017
From: karl.reinl at ...16... (Karl Reinl)
Date: Sun, 23 Jul 2017 07:19:54 +1200
Subject: [Gambas-devel] Gambas to Git(Lab)
In-Reply-To: <op.y3si830ydlsaci@...102...>
References: <op.y3si830ydlsaci@...102...>
Message-ID: <1500751194.9945.2.camel@...763...>

Am Samstag, den 22.07.2017, 20:35 +0200 schrieb Adrien Prokopowicz:
> Hello everyone,
> 
> In an effort to both switch the Gambas project versioning to Git, and to  
> move away
>  from Sourceforge, I imported the whole repository to GitLab. You can see  
> it here :
> 
> https://gitlab.com/prokopyl/gambas
> 
>  From what I see, all history, commits, tags and branches have been  
> successfully
> imported, and authors have been correctly mapped from their Sourceforge  
> usernames to
> Git full names and emails (the SVN/Git mapping file is attached).
> 
> I know there has been some GitHub vs. GitLab debate on the mailing list  
> somewhere,
> but it didn't seem to have produced anything, so I just picked one.
> Since nothing I have done is GitLab-specific (it's just a plain Git  
> repository for now),
> we can easily use GitHub too.
> I personally picked GitLab simply because we can easily retrieve data  
> (issues, wiki and such)
>  from a generated archive if we ever want to switch, and their integrated  
> CI solution
> seems less restricted than Travis (but I didn't go that far with it).
> 
> For now, all I did was cloning the entire SVN repo on the server that  
> hosts the
> playground (for its symmetric 100Mbit/s connection :) ), then using  
> git-svn to
> create a git repo from the clone, and then push it all to GitLab.
> 
> I'm currently trying to set up Continuous Integration to generate Ubuntu  
> packages, and
> maybe for more distributions later (RHEL/CentOS, Debian, ArchLinux, ?).
> 
> I know we won't switch to Git right now, I'm at least waiting for 3.10 to  
> be released
> so everything can calm down. :)
> However I would like your feedback : what do you think is needed to make  
> Gambas
> successfully switch to Git ? (Whichever host we end up choosing).

Salut Adrien,

a short test shows me the Copy Links get a 404.
But I do not know anything about GitXX


-- 
Amicalement
Charlie
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Bildschirmfoto vom 2017-07-23 07:16:02.png
Type: image/png
Size: 62572 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20170723/b4ef4c63/attachment.png>

From adrien.prokopowicz at ...176...  Sat Jul 22 21:43:57 2017
From: adrien.prokopowicz at ...176... (Adrien Prokopowicz)
Date: Sat, 22 Jul 2017 21:43:57 +0200
Subject: [Gambas-devel] Gambas to Git(Lab)
In-Reply-To: <1500751194.9945.2.camel@...763...>
References: <op.y3si830ydlsaci@...102...>
 <1500751194.9945.2.camel@...763...>
Message-ID: <op.y3smfjiwdlsaci@...102...>

Le Sat, 22 Jul 2017 21:19:54 +0200, Karl Reinl <karl.reinl at ...16...> a  
?crit:
>
> Salut Adrien,
>
> a short test shows me the Copy Links get a 404.
> But I do not know anything about GitXX
>
>

Hi Karl,

These links are just the messages for commits that Beno?t wrote 9 years  
ago.
They apparently point to the old 2.0 repository on sourceforge, which does
not exist anymore. You can see the corresponding commit on sourceforge[0].

Since it is just an old message, I don't think you have to worry about
these broken links. :)

Regards,

[0] https://sourceforge.net/p/gambas/code/8167/log/?path=/gambas/trunk/NEWS
-- 
Adrien Prokopowicz



From gambas at ...1...  Sun Jul 23 01:33:09 2017
From: gambas at ...1... (=?UTF-8?Q?Beno=c3=aet_Minisini?=)
Date: Sun, 23 Jul 2017 01:33:09 +0200
Subject: [Gambas-devel] Fwd: Re:  Gambas to Git(Lab)
In-Reply-To: <fb4f3865-2bf1-09a6-6363-db2bfdf63995@...1...>
References: <fb4f3865-2bf1-09a6-6363-db2bfdf63995@...1...>
Message-ID: <1bda074c-b929-6377-bf49-d82ea33b2ef9@...1...>

Le 22/07/2017 ? 20:35, Adrien Prokopowicz a ?crit :
> Hello everyone,
> 
> In an effort to both switch the Gambas project versioning to Git, and to 
> move away
> from Sourceforge, I imported the whole repository to GitLab. You can see 
> it here :
> 
> https://gitlab.com/prokopyl/gambas
> 
>  From what I see, all history, commits, tags and branches have been 
> successfully
> imported, and authors have been correctly mapped from their Sourceforge 
> usernames to
> Git full names and emails (the SVN/Git mapping file is attached).
> 
> I know there has been some GitHub vs. GitLab debate on the mailing list 
> somewhere,
> but it didn't seem to have produced anything, so I just picked one.
> Since nothing I have done is GitLab-specific (it's just a plain Git 
> repository for now),
> we can easily use GitHub too.
> I personally picked GitLab simply because we can easily retrieve data 
> (issues, wiki and such)
> from a generated archive if we ever want to switch, and their integrated 
> CI solution
> seems less restricted than Travis (but I didn't go that far with it).
> 
> For now, all I did was cloning the entire SVN repo on the server that 
> hosts the
> playground (for its symmetric 100Mbit/s connection :) ), then using 
> git-svn to
> create a git repo from the clone, and then push it all to GitLab.
> 
> I'm currently trying to set up Continuous Integration to generate Ubuntu 
> packages, and
> maybe for more distributions later (RHEL/CentOS, Debian, ArchLinux, ?).
> 
> I know we won't switch to Git right now, I'm at least waiting for 3.10 
> to be released
> so everything can calm down. :)
> However I would like your feedback : what do you think is needed to make 
> Gambas
> successfully switch to Git ? (Whichever host we end up choosing).
> 
> Regards,
> 

The problem I encountered when moving from subversion to git in my job 
is that git does not really have tags and branches that behave the same 
way. I.e. being actual independent trees.

A recently added feature named "working tree" in git seems to help to do 
the same thing: developing on different versions at the same time.

Or maybe I didn't understand how to use git for that?

Regards,

-- 
Beno?t Minisini

-- 
Beno?t Minisini



From adrien.prokopowicz at ...176...  Sun Jul 23 04:01:04 2017
From: adrien.prokopowicz at ...176... (Adrien Prokopowicz)
Date: Sun, 23 Jul 2017 04:01:04 +0200
Subject: [Gambas-devel] Gambas to Git(Lab)
In-Reply-To: <1bda074c-b929-6377-bf49-d82ea33b2ef9@...1...>
References: <fb4f3865-2bf1-09a6-6363-db2bfdf63995@...1...>
 <1bda074c-b929-6377-bf49-d82ea33b2ef9@...1...>
Message-ID: <op.y3s3v2cwdlsaci@...102...>

Le Sun, 23 Jul 2017 01:33:09 +0200, Beno?t Minisini via Gambas-devel  
<gambas-devel at lists.sourceforge.net> a ?crit:
>
> The problem I encountered when moving from subversion to git in my job  
> is that git does not really have tags and branches that behave the same  
> way. I.e. being actual independent trees.
>
> A recently added feature named "working tree" in git seems to help to do  
> the same thing: developing on different versions at the same time.
>
> Or maybe I didn't understand how to use git for that?
>
> Regards,
>

You can work on different versions/branches at the same time. It's just  
that branches
in Git are waay different from SVN branches. :)

In SVN, both branches and tags do not really exist : they are just separate
directories, and creating a new branch/tag essentially means copying the  
entire
directory over, from /trunk to /branches/3.10 for example.
(SVN actually uses some Copy-on-Write mechanisms under the hood, such as  
hard-links,
but from the user point of view it is just a regular copy).

In Git however, branches are more of a diverged history : they share the  
same history
up to the point where you create the branch, but then the commits you make  
in each
branch are completely separate.
For example, you create a new 3.10 branch from the master (main) branch.  
The commits
you add to the 3.10 branch will not be applied to the master branch, and  
if you switch
back to master, you are in the same state you were before creating the  
branch, and from
there you can add some commits to master (which will not affect 3.10).

You can check out the Git documentation about branches here [0]. It has  
diagrams
and all the commands needed to work with branches. But if you (in the  
broad sense, not
just Beno?t) have questions, you can just ask me. :)

What I really like about workflows based on Git branches, is that they  
make it really
easy to start working on new (and unfinished) features without submitting  
them
to the main branch. You simply create a new branch and start working in  
it, allowing
everyone to see your work and provide feedback, without having to include  
it in the
next release.
And when your work is ready, you just merge it back into the main branch.  
:)

A recent example of this would be the gb.term.form component : Fabien  
started working
on it at the time of Gambas 3.9, but just said it is not ready for 3.10.  
If the unfinished
component is in its own branch, then you can just release what is on the  
main branch
without worrying. (This kind of workflow is also explained in the Git  
documentation,
see here[1]).

What makes this workflow even more awesome is the fact than anybody (on  
GitLab/GitHub)
can fork the Gambas repository (i.e. copy the repository into a new one  
they own),
make changes in their repository, and then ask to merge the changes  
through a
Merge Request[2] (GitHub calls these Pull Requests). You can then review  
their
changes, approve them (or not), and merge them.
This is great for allowing one-time contributors to participate without  
having to
give them full permissions on the repository (and it's much better than  
sending
a patch for review). :)

(? and here I made a hundred-page-long message again. Sorry about that,  
but Git
is exciting !)

Regards,

[0]  
https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
[1] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows
[2] https://docs.gitlab.com/ee/user/project/merge_requests/index.html

-- 
Adrien Prokopowicz



From chrisml at ...757...  Sun Jul 23 12:02:30 2017
From: chrisml at ...757... (Christof Thalhofer)
Date: Sun, 23 Jul 2017 12:02:30 +0200
Subject: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)
In-Reply-To: <1bda074c-b929-6377-bf49-d82ea33b2ef9@...1...>
References: <fb4f3865-2bf1-09a6-6363-db2bfdf63995@...1...>
 <1bda074c-b929-6377-bf49-d82ea33b2ef9@...1...>
Message-ID: <dc6a5e55-6098-c328-048c-ff9973491581@...757...>

Am 23.07.2017 um 01:33 schrieb Beno?t Minisini via Gambas-devel:

> The problem I encountered when moving from subversion to git in my job 
> is that git does not really have tags and branches that behave the same 
> way. I.e. being actual independent trees.
> 
> A recently added feature named "working tree" in git seems to help to do 
> the same thing: developing on different versions at the same time.

I did not use that feature, as I only switch between different branches
in my code (maybe one for each release). But it seems to have advantages
if you have very big repositories (where switching between branches
costs too much time):

https://stackoverflow.com/questions/31935776/what-would-i-use-git-worktree-for

> Or maybe I didn't understand how to use git for that?

Here is a good explanation of common git workflows:
https://www.atlassian.com/git/tutorials/comparing-workflows

Why do you want to develop in different versions at the same time, to
fix bugs? Look at "Maintenance Branches" and "Hotfix", maybe that is,
what you wanted to do?

I am unsure what sort of development workflow would be the best for Gambas.

If I look at a big projekt for example that put its codebase to Git ?
OTRS ? they did it so:

https://github.com/OTRS/otrs

Look there at the branches and tags. They seem to have ongoing
development in master with branches for the "big" releases. Tags are
used to point to subreleases.


Alles Gute

Christof Thalhofer

-- 
Dies ist keine Signatur

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20170723/5d500b5c/attachment.sig>

From chrisml at ...757...  Sun Jul 23 12:03:45 2017
From: chrisml at ...757... (Christof Thalhofer)
Date: Sun, 23 Jul 2017 12:03:45 +0200
Subject: [Gambas-devel] Gambas to Git(Lab)
In-Reply-To: <op.y3s3v2cwdlsaci@...102...>
References: <fb4f3865-2bf1-09a6-6363-db2bfdf63995@...1...>
 <1bda074c-b929-6377-bf49-d82ea33b2ef9@...1...>
 <op.y3s3v2cwdlsaci@...102...>
Message-ID: <5db13c3a-789a-8258-14d9-2049368628fd@...757...>

Am 23.07.2017 um 04:01 schrieb Adrien Prokopowicz:

> but Git
> is exciting !)

Yes! Full Ack!
:-)

I love to work with Git. It makes the horizont so much wider.


Alles Gute

Christof Thalhofer

-- 
Dies ist keine Signatur

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20170723/870293b4/attachment.sig>

From mckaygerhard at ...176...  Sun Jul 23 16:17:54 2017
From: mckaygerhard at ...176... (PICCORO McKAY Lenz)
Date: Sun, 23 Jul 2017 09:47:54 -0430
Subject: [Gambas-devel] Gambas to Git(Lab)
Message-ID: <CALci+FSR6vmdAzWtzDix+gvtBzsPqwLA9-KCWafB9Gj8XgipvQ@...178...>

git have REAL branchs and tas.. SVN do just copy's, also SVN its
centraliced a problem in team collaborations , due the fusion of resulting
jobs comes in many deadlocks at the developer side.. of course at the
server central side are very easy to mantain.. but we must see the horizont

i'm not avocate of "up to date things" but in this way are really need..
also the SF interface are so slower when i goin to the cybercafe.. due i'm
not have internet access at my home..

so in many ways the SVN (and for me that the most important part) can work
offline.. SVN need connection alive to mark commits... its very tedious for
me use SVN due i not have internet connection.. so  that the mayor
problem.. the very centralised behavior that git does are more flexible!


> Date: Sun, 23 Jul 2017 01:33:09 +0200
> From: Beno?t Minisini <gambas at ...1...>
> The problem I encountered when moving from subversion to git in my job
> is that git does not really have tags and branches that behave the same
> way. I.e. being actual independent trees.
>
> A recently added feature named "working tree" in git seems to help to do
> the same thing: developing on different versions at the same time.
>
> Or maybe I didn't understand how to use git for that?
>
> Regards,
>
> --
> Beno?t Minisini
>
> --
> Beno?t Minisini
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 23 Jul 2017 04:01:04 +0200
> From: "Adrien Prokopowicz" <adrien.prokopowicz at ...176...>
> To: "mailing list for gambas developers"
>         <gambas-devel at lists.sourceforge.net>
> Subject: Re: [Gambas-devel] Gambas to Git(Lab)
> Message-ID: <op.y3s3v2cwdlsaci at ...102...>
> Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
>
> Le Sun, 23 Jul 2017 01:33:09 +0200, Beno?t Minisini via Gambas-devel
> <gambas-devel at lists.sourceforge.net> a ?crit:
> >
> > The problem I encountered when moving from subversion to git in my job
> > is that git does not really have tags and branches that behave the same
> > way. I.e. being actual independent trees.
> >
> > A recently added feature named "working tree" in git seems to help to do
> > the same thing: developing on different versions at the same time.
> >
> > Or maybe I didn't understand how to use git for that?
> >
> > Regards,
> >
>
> You can work on different versions/branches at the same time. It's just
> that branches
> in Git are waay different from SVN branches. :)
>
> In SVN, both branches and tags do not really exist : they are just separate
> directories, and creating a new branch/tag essentially means copying the
> entire
> directory over, from /trunk to /branches/3.10 for example.
> (SVN actually uses some Copy-on-Write mechanisms under the hood, such as
> hard-links,
> but from the user point of view it is just a regular copy).
>
> In Git however, branches are more of a diverged history : they share the
> same history
> up to the point where you create the branch, but then the commits you make
> in each
> branch are completely separate.
> For example, you create a new 3.10 branch from the master (main) branch.
> The commits
> you add to the 3.10 branch will not be applied to the master branch, and
> if you switch
> back to master, you are in the same state you were before creating the
> branch, and from
> there you can add some commits to master (which will not affect 3.10).
>
> You can check out the Git documentation about branches here [0]. It has
> diagrams
> and all the commands needed to work with branches. But if you (in the
> broad sense, not
> just Beno?t) have questions, you can just ask me. :)
>
> What I really like about workflows based on Git branches, is that they
> make it really
> easy to start working on new (and unfinished) features without submitting
> them
> to the main branch. You simply create a new branch and start working in
> it, allowing
> everyone to see your work and provide feedback, without having to include
> it in the
> next release.
> And when your work is ready, you just merge it back into the main branch.
> :)
>
> A recent example of this would be the gb.term.form component : Fabien
> started working
> on it at the time of Gambas 3.9, but just said it is not ready for 3.10.
> If the unfinished
> component is in its own branch, then you can just release what is on the
> main branch
> without worrying. (This kind of workflow is also explained in the Git
> documentation,
> see here[1]).
>
> What makes this workflow even more awesome is the fact than anybody (on
> GitLab/GitHub)
> can fork the Gambas repository (i.e. copy the repository into a new one
> they own),
> make changes in their repository, and then ask to merge the changes
> through a
> Merge Request[2] (GitHub calls these Pull Requests). You can then review
> their
> changes, approve them (or not), and merge them.
> This is great for allowing one-time contributors to participate without
> having to
> give them full permissions on the repository (and it's much better than
> sending
> a patch for review). :)
>
> (? and here I made a hundred-page-long message again. Sorry about that,
> but Git
> is exciting !)
>
> Regards,
>
> [0]
> https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
> [1] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows
> [2] https://docs.gitlab.com/ee/user/project/merge_requests/index.html
>
> --
> Adrien Prokopowicz
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sun, 23 Jul 2017 12:02:30 +0200
> From: Christof Thalhofer <chrisml at ...757...>
> To: mailing list for gambas developers
>         <gambas-devel at lists.sourceforge.net>
> Subject: Re: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)
> Message-ID: <dc6a5e55-6098-c328-048c-ff9973491581 at ...757...>
> Content-Type: text/plain; charset="utf-8"
>
> Am 23.07.2017 um 01:33 schrieb Beno?t Minisini via Gambas-devel:
>
> > The problem I encountered when moving from subversion to git in my job
> > is that git does not really have tags and branches that behave the same
> > way. I.e. being actual independent trees.
> >
> > A recently added feature named "working tree" in git seems to help to do
> > the same thing: developing on different versions at the same time.
>
> I did not use that feature, as I only switch between different branches
> in my code (maybe one for each release). But it seems to have advantages
> if you have very big repositories (where switching between branches
> costs too much time):
>
> https://stackoverflow.com/questions/31935776/what-would-
> i-use-git-worktree-for
>
> > Or maybe I didn't understand how to use git for that?
>
> Here is a good explanation of common git workflows:
> https://www.atlassian.com/git/tutorials/comparing-workflows
>
> Why do you want to develop in different versions at the same time, to
> fix bugs? Look at "Maintenance Branches" and "Hotfix", maybe that is,
> what you wanted to do?
>
> I am unsure what sort of development workflow would be the best for Gambas.
>
> If I look at a big projekt for example that put its codebase to Git ?
> OTRS ? they did it so:
>
> https://github.com/OTRS/otrs
>
> Look there at the branches and tags. They seem to have ongoing
> development in master with branches for the "big" releases. Tags are
> used to point to subreleases.
>
>
> Alles Gute
>
> Christof Thalhofer
>
> --
> Dies ist keine Signatur
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 819 bytes
> Desc: OpenPGP digital signature
>
> ------------------------------
>
> Message: 5
> Date: Sun, 23 Jul 2017 12:03:45 +0200
> From: Christof Thalhofer <chrisml at ...757...>
> To: mailing list for gambas developers
>         <gambas-devel at lists.sourceforge.net>
> Subject: Re: [Gambas-devel] Gambas to Git(Lab)
> Message-ID: <5db13c3a-789a-8258-14d9-2049368628fd at ...757...>
> Content-Type: text/plain; charset="utf-8"
>
> Am 23.07.2017 um 04:01 schrieb Adrien Prokopowicz:
>
> > but Git
> > is exciting !)
>
> Yes! Full Ack!
> :-)
>
> I love to work with Git. It makes the horizont so much wider.
>
>
> Alles Gute
>
> Christof Thalhofer
>
> --
> Dies ist keine Signatur
>
> -------------- next part --------------
> A non-text attachment was scrubbed...
> Name: signature.asc
> Type: application/pgp-signature
> Size: 819 bytes
> Desc: OpenPGP digital signature
>
> ------------------------------
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
> ------------------------------
>
> Subject: Digest Footer
>
> _______________________________________________
> Gambas-devel mailing list
> Gambas-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>
>
> ------------------------------
>
> End of Gambas-devel Digest, Vol 112, Issue 3
> ********************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20170723/71f1c1c8/attachment.html>

From mckaygerhard at ...176...  Sun Jul 23 16:24:34 2017
From: mckaygerhard at ...176... (PICCORO McKAY Lenz)
Date: Sun, 23 Jul 2017 09:54:34 -0430
Subject: [Gambas-devel] Gambas group taken in gitlab..
Message-ID: <CALci+FTnrOr_W+tB85SSPSrNBngWj0mB2vLWKs8WaNT3e=vyEQ@...178...>

and i see that https://gitlab.com/gambas was already taken.. to setup a
property group and integration collaboration..

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-07-23 9:47 GMT-04:30 PICCORO McKAY Lenz <mckaygerhard at ...176...>:

> git have REAL branchs and tas.. SVN do just copy's, also SVN its
> centraliced a problem in team collaborations , due the fusion of resulting
> jobs comes in many deadlocks at the developer side.. of course at the
> server central side are very easy to mantain.. but we must see the horizont
>
> i'm not avocate of "up to date things" but in this way are really need..
> also the SF interface are so slower when i goin to the cybercafe.. due i'm
> not have internet access at my home..
>
> so in many ways the SVN (and for me that the most important part) can work
> offline.. SVN need connection alive to mark commits... its very tedious for
> me use SVN due i not have internet connection.. so  that the mayor
> problem.. the very centralised behavior that git does are more flexible!
>
>
>> Date: Sun, 23 Jul 2017 01:33:09 +0200
>> From: Beno?t Minisini <gambas at ...1...>
>> The problem I encountered when moving from subversion to git in my job
>> is that git does not really have tags and branches that behave the same
>> way. I.e. being actual independent trees.
>>
>> A recently added feature named "working tree" in git seems to help to do
>> the same thing: developing on different versions at the same time.
>>
>> Or maybe I didn't understand how to use git for that?
>>
>> Regards,
>>
>> --
>> Beno?t Minisini
>>
>> --
>> Beno?t Minisini
>>
>>
>>
>> ------------------------------
>>
>> Message: 3
>> Date: Sun, 23 Jul 2017 04:01:04 +0200
>> From: "Adrien Prokopowicz" <adrien.prokopowicz at ...176...>
>> To: "mailing list for gambas developers"
>>         <gambas-devel at lists.sourceforge.net>
>> Subject: Re: [Gambas-devel] Gambas to Git(Lab)
>> Message-ID: <op.y3s3v2cwdlsaci at ...102...>
>> Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes
>>
>> Le Sun, 23 Jul 2017 01:33:09 +0200, Beno?t Minisini via Gambas-devel
>> <gambas-devel at lists.sourceforge.net> a ?crit:
>> >
>> > The problem I encountered when moving from subversion to git in my job
>> > is that git does not really have tags and branches that behave the same
>> > way. I.e. being actual independent trees.
>> >
>> > A recently added feature named "working tree" in git seems to help to do
>> > the same thing: developing on different versions at the same time.
>> >
>> > Or maybe I didn't understand how to use git for that?
>> >
>> > Regards,
>> >
>>
>> You can work on different versions/branches at the same time. It's just
>> that branches
>> in Git are waay different from SVN branches. :)
>>
>> In SVN, both branches and tags do not really exist : they are just
>> separate
>> directories, and creating a new branch/tag essentially means copying the
>> entire
>> directory over, from /trunk to /branches/3.10 for example.
>> (SVN actually uses some Copy-on-Write mechanisms under the hood, such as
>> hard-links,
>> but from the user point of view it is just a regular copy).
>>
>> In Git however, branches are more of a diverged history : they share the
>> same history
>> up to the point where you create the branch, but then the commits you make
>> in each
>> branch are completely separate.
>> For example, you create a new 3.10 branch from the master (main) branch.
>> The commits
>> you add to the 3.10 branch will not be applied to the master branch, and
>> if you switch
>> back to master, you are in the same state you were before creating the
>> branch, and from
>> there you can add some commits to master (which will not affect 3.10).
>>
>> You can check out the Git documentation about branches here [0]. It has
>> diagrams
>> and all the commands needed to work with branches. But if you (in the
>> broad sense, not
>> just Beno?t) have questions, you can just ask me. :)
>>
>> What I really like about workflows based on Git branches, is that they
>> make it really
>> easy to start working on new (and unfinished) features without submitting
>> them
>> to the main branch. You simply create a new branch and start working in
>> it, allowing
>> everyone to see your work and provide feedback, without having to include
>> it in the
>> next release.
>> And when your work is ready, you just merge it back into the main branch.
>> :)
>>
>> A recent example of this would be the gb.term.form component : Fabien
>> started working
>> on it at the time of Gambas 3.9, but just said it is not ready for 3.10.
>> If the unfinished
>> component is in its own branch, then you can just release what is on the
>> main branch
>> without worrying. (This kind of workflow is also explained in the Git
>> documentation,
>> see here[1]).
>>
>> What makes this workflow even more awesome is the fact than anybody (on
>> GitLab/GitHub)
>> can fork the Gambas repository (i.e. copy the repository into a new one
>> they own),
>> make changes in their repository, and then ask to merge the changes
>> through a
>> Merge Request[2] (GitHub calls these Pull Requests). You can then review
>> their
>> changes, approve them (or not), and merge them.
>> This is great for allowing one-time contributors to participate without
>> having to
>> give them full permissions on the repository (and it's much better than
>> sending
>> a patch for review). :)
>>
>> (? and here I made a hundred-page-long message again. Sorry about that,
>> but Git
>> is exciting !)
>>
>> Regards,
>>
>> [0]
>> https://git-scm.com/book/en/v2/Git-Branching-Basic-Branching-and-Merging
>> [1] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows
>> [2] https://docs.gitlab.com/ee/user/project/merge_requests/index.html
>>
>> --
>> Adrien Prokopowicz
>>
>>
>>
>> ------------------------------
>>
>> Message: 4
>> Date: Sun, 23 Jul 2017 12:02:30 +0200
>> From: Christof Thalhofer <chrisml at ...757...>
>> To: mailing list for gambas developers
>>         <gambas-devel at lists.sourceforge.net>
>> Subject: Re: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)
>> Message-ID: <dc6a5e55-6098-c328-048c-ff9973491581 at ...757...>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Am 23.07.2017 um 01:33 schrieb Beno?t Minisini via Gambas-devel:
>>
>> > The problem I encountered when moving from subversion to git in my job
>> > is that git does not really have tags and branches that behave the same
>> > way. I.e. being actual independent trees.
>> >
>> > A recently added feature named "working tree" in git seems to help to do
>> > the same thing: developing on different versions at the same time.
>>
>> I did not use that feature, as I only switch between different branches
>> in my code (maybe one for each release). But it seems to have advantages
>> if you have very big repositories (where switching between branches
>> costs too much time):
>>
>> https://stackoverflow.com/questions/31935776/what-would-i-
>> use-git-worktree-for
>>
>> > Or maybe I didn't understand how to use git for that?
>>
>> Here is a good explanation of common git workflows:
>> https://www.atlassian.com/git/tutorials/comparing-workflows
>>
>> Why do you want to develop in different versions at the same time, to
>> fix bugs? Look at "Maintenance Branches" and "Hotfix", maybe that is,
>> what you wanted to do?
>>
>> I am unsure what sort of development workflow would be the best for
>> Gambas.
>>
>> If I look at a big projekt for example that put its codebase to Git ?
>> OTRS ? they did it so:
>>
>> https://github.com/OTRS/otrs
>>
>> Look there at the branches and tags. They seem to have ongoing
>> development in master with branches for the "big" releases. Tags are
>> used to point to subreleases.
>>
>>
>> Alles Gute
>>
>> Christof Thalhofer
>>
>> --
>> Dies ist keine Signatur
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: signature.asc
>> Type: application/pgp-signature
>> Size: 819 bytes
>> Desc: OpenPGP digital signature
>>
>> ------------------------------
>>
>> Message: 5
>> Date: Sun, 23 Jul 2017 12:03:45 +0200
>> From: Christof Thalhofer <chrisml at ...757...>
>> To: mailing list for gambas developers
>>         <gambas-devel at lists.sourceforge.net>
>> Subject: Re: [Gambas-devel] Gambas to Git(Lab)
>> Message-ID: <5db13c3a-789a-8258-14d9-2049368628fd at ...757...>
>> Content-Type: text/plain; charset="utf-8"
>>
>> Am 23.07.2017 um 04:01 schrieb Adrien Prokopowicz:
>>
>> > but Git
>> > is exciting !)
>>
>> Yes! Full Ack!
>> :-)
>>
>> I love to work with Git. It makes the horizont so much wider.
>>
>>
>> Alles Gute
>>
>> Christof Thalhofer
>>
>> --
>> Dies ist keine Signatur
>>
>> -------------- next part --------------
>> A non-text attachment was scrubbed...
>> Name: signature.asc
>> Type: application/pgp-signature
>> Size: 819 bytes
>> Desc: OpenPGP digital signature
>>
>> ------------------------------
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>>
>> ------------------------------
>>
>> Subject: Digest Footer
>>
>> _______________________________________________
>> Gambas-devel mailing list
>> Gambas-devel at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/gambas-devel
>>
>>
>> ------------------------------
>>
>> End of Gambas-devel Digest, Vol 112, Issue 3
>> ********************************************
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20170723/c25db45e/attachment.html>

From gambas at ...1...  Sun Jul 23 17:59:56 2017
From: gambas at ...1... (=?UTF-8?Q?Beno=c3=aet_Minisini?=)
Date: Sun, 23 Jul 2017 17:59:56 +0200
Subject: [Gambas-devel] Gambas group taken in gitlab..
In-Reply-To: <CALci+FTnrOr_W+tB85SSPSrNBngWj0mB2vLWKs8WaNT3e=vyEQ@...178...>
References: <CALci+FTnrOr_W+tB85SSPSrNBngWj0mB2vLWKs8WaNT3e=vyEQ@...178...>
Message-ID: <d33cf214-46d3-0aa5-9794-b8b763397ffe@...1...>

Le 23/07/2017 ? 16:24, PICCORO McKAY Lenz a ?crit :
> and i see that https://gitlab.com/gambas was already taken.. to setup a 
> property group and integration collaboration..
> 
> Lenz McKAY Gerardo (PICCORO)
> http://qgqlochekone.blogspot.com
> 

It's me. :-)

I created that user in prevision of the switch to git.

-- 
Beno?t Minisini



From mckaygerhard at ...176...  Sun Jul 23 20:01:47 2017
From: mckaygerhard at ...176... (PICCORO McKAY Lenz)
Date: Sun, 23 Jul 2017 13:31:47 -0430
Subject: [Gambas-devel] Gambas group taken in gitlab..
In-Reply-To: <d33cf214-46d3-0aa5-9794-b8b763397ffe@...1...>
References: <CALci+FTnrOr_W+tB85SSPSrNBngWj0mB2vLWKs8WaNT3e=vyEQ@...178...>
 <d33cf214-46d3-0aa5-9794-b8b763397ffe@...1...>
Message-ID: <CALci+FTPkFCNkvt5ebs6QK7rbp4DxwFh2Ji_rCCnRoyXG5f-kw@...178...>

benoit, you can inegrating the github, gitlab and SF groups/repositories,
like i do with venenux/elsistema in gitlab and github..

when something made a commit in the repo, gitlab make a autocommit to the
folk in github

there's ahother way, using git in your local, but its not automatic..
depends of user,and if users has too many things in mind.. something forget
to do that..

also has some hooks,

also trigger to twitter or mail on each commit, like venenux does with list

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2017-07-23 11:29 GMT-04:30 Beno?t Minisini <gambas at ...1...>:

> Le 23/07/2017 ? 16:24, PICCORO McKAY Lenz a ?crit :
>
>> and i see that https://gitlab.com/gambas was already taken.. to setup a
>> property group and integration collaboration..
>>
>> Lenz McKAY Gerardo (PICCORO)
>> http://qgqlochekone.blogspot.com
>>
>>
> It's me. :-)
>
> I created that user in prevision of the switch to git.
>
> --
> Beno?t Minisini
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20170723/12977143/attachment.html>

From mckaygerhard at ...176...  Sun Jul 23 21:22:22 2017
From: mckaygerhard at ...176... (PICCORO McKAY Lenz)
Date: Sun, 23 Jul 2017 14:52:22 -0430
Subject: [Gambas-devel] user gambas -> group gambas
Message-ID: <CALci+FS9ewRJwrNdsRGvQMKYuKBB4n0roALSd0z9c3w6+-k6NQ@...178...>

Benoit  i suggested change the user gambas to a group.. due this way can
handle common prospect over same group of developming..

for understand that, see some group examples as :
https://github.com/owncloud that have the projects and the people involved

Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20170723/17dc146e/attachment.html>

From taboege at ...176...  Fri Jul 28 15:57:58 2017
From: taboege at ...176... (Tobias Boege)
Date: Fri, 28 Jul 2017 15:57:58 +0200
Subject: [Gambas-devel] Gambas 3.10 - gb.web.feed
In-Reply-To: <28a5443e-28ac-c042-c57c-52dd2a817b72@...1...>
References: <20170701194657.GC568@...756...>
 <28a5443e-28ac-c042-c57c-52dd2a817b72@...1...>
Message-ID: <20170728135758.GF602@...756...>

On Sat, 22 Jul 2017, Beno?t Minisini wrote:
> Le 01/07/2017 ? 21:46, Tobias Boege a ?crit :
> > On Sat, 01 Jul 2017, Beno?t Minisini via Gambas-devel wrote:
> > > I will have some time next week, and I want to release Gambas 3.10.
> > 
> > Hi Benoit,
> > 
> > Gambas 3.10 would include the new gb.web.feed, right? I have some local
> > changes pending which better be committed before the component is first
> > included in a stable version.
> > 
> > As I mentioned earlier, I want Date values in RSS to be accompanied by
> > an RFC822 timezone string, because I want to give the user a way to
> > specify the timezone string when they create RSS documents (e.g. an RSS
> > feed of a local newspaper in Germany should not have the timezone of
> > the US-located server machine where the feed is put together, but the
> > German timezone relevant to the article).
> > 
> > I need the following:
> > 
> >    1. A way to get the timezone string out of the RFC822 parser in gb.util.
> >    2. Two functions which convert between RFC822 timezone string and
> >       a numeric representation (number of seconds from UTC?) I believe
> >       those functions are already in gb.util, but Private.
> >    3. An RFC822 timezone string for the local system timezone, as a
> >       reasonable default when the user gives no timezone.
> >    4. Functions which convert a (date, timezone) pair, which is to be
> >       understood as "<date> is in/relative to <timezone>" to another
> >       timezone.
> > 
> > I think if 1. and 2. are there, I can implement 3. and 4. by myself.
> > Having 4. would give me a clean conscience, as I intend to store the
> > timezone inside the component just as an RFC822 timezone string and
> > let the user handle calculations with timezones if they need it.
> > Point 4. then gives the user the needed primitives.
> > 
> > Please also look at [1] where I listed some doubts I have about the
> > current RFC822 functions in gb.util.
> > 
> > Regards,
> > Tobi
> > 
> > [1] https://sourceforge.net/p/gambas/mailman/message/35810371/
> > 
> 
> Sorry, I forgot to deal with your requests.
> 

And I came back from vacation just recently. As I see 3.10 wasn't released
yet. I'll try to push the changes today, if we can agree on them.

> You should internally use Gambas date, not strings, as Gambas date are
> internally UTC timestamps.
> 
> The trick is that when you make a date with Date(Year, Month, ...), the
> values you are giving are in the local timezone.
> 
> This is the reason why I'm substracting Frac(Date(Now)): it moves the date
> to the UTC time zone (as Now is in local time, the fractional part of
> Date(Now) converted to float is the timezone).
> 
> Frac(Date(Now)) and -(System.TimeZone / 86400) are the same value (up to the
> 4th decimal digit, because of different precision).
> 
> And isn't the timezone mandatory in a RFC822 date?

Yes, the timezone is mandatory there.

So, how about this: I make a class called RssDate where I store a UTC-based
timestamp (aka Date) and a timezone string. As I mentioned before, I think
the timezone string is necessary to let the user specify what timezone the
date will be printed in.

When an RFC822 date is read, I want to have its timezone string and the
timestamp of that date converted to UTC. When an RFC822 date is written,
I take the UTC timestamp and convert it to the string representation in
the timezone that the user wants to print the date in.

If that sounds reasonable, I can get to work now.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk



From gambas at ...1...  Fri Jul 28 16:16:03 2017
From: gambas at ...1... (=?UTF-8?Q?Beno=c3=aet_Minisini?=)
Date: Fri, 28 Jul 2017 16:16:03 +0200
Subject: [Gambas-devel] Gambas 3.10 - gb.web.feed
In-Reply-To: <20170728135758.GF602@...756...>
References: <20170701194657.GC568@...756...>
 <28a5443e-28ac-c042-c57c-52dd2a817b72@...1...>
 <20170728135758.GF602@...756...>
Message-ID: <f72fc1ce-3945-057b-57c9-837abab1a202@...1...>

Le 28/07/2017 ? 15:57, Tobias Boege a ?crit :
>>
>> Sorry, I forgot to deal with your requests.
>>
> 
> And I came back from vacation just recently. As I see 3.10 wasn't released
> yet. I'll try to push the changes today, if we can agree on them.
> 

I go to vacation tommorow, and come back next week. So I think I will 
make the release in a week, so that you have more time.

>> You should internally use Gambas date, not strings, as Gambas date are
>> internally UTC timestamps.
>>
>> The trick is that when you make a date with Date(Year, Month, ...), the
>> values you are giving are in the local timezone.
>>
>> This is the reason why I'm substracting Frac(Date(Now)): it moves the date
>> to the UTC time zone (as Now is in local time, the fractional part of
>> Date(Now) converted to float is the timezone).
>>
>> Frac(Date(Now)) and -(System.TimeZone / 86400) are the same value (up to the
>> 4th decimal digit, because of different precision).
>>
>> And isn't the timezone mandatory in a RFC822 date?
> 
> Yes, the timezone is mandatory there.
> 
> So, how about this: I make a class called RssDate where I store a UTC-based
> timestamp (aka Date) and a timezone string. As I mentioned before, I think
> the timezone string is necessary to let the user specify what timezone the
> date will be printed in.
> 
> When an RFC822 date is read, I want to have its timezone string and the
> timestamp of that date converted to UTC. When an RFC822 date is written,
> I take the UTC timestamp and convert it to the string representation in
> the timezone that the user wants to print the date in.
> 
> If that sounds reasonable, I can get to work now.
> 
> Regards,
> Tobi
> 

Why do you need the timezone part of the RFC822 date as a string? Why 
not just using Gambas Date and the Date.ToRFC822() / Date.FromRFC822() 
functions?

-- 
Beno?t Minisini



From adrien.prokopowicz at ...176...  Fri Jul 28 16:35:44 2017
From: adrien.prokopowicz at ...176... (Adrien Prokopowicz)
Date: Fri, 28 Jul 2017 16:35:44 +0200
Subject: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)
In-Reply-To: <dc6a5e55-6098-c328-048c-ff9973491581@...757...>
References: <fb4f3865-2bf1-09a6-6363-db2bfdf63995@...1...>
 <1bda074c-b929-6377-bf49-d82ea33b2ef9@...1...>
 <dc6a5e55-6098-c328-048c-ff9973491581@...757...>
Message-ID: <op.y33b5ujadlsaci@...102...>

Le Sun, 23 Jul 2017 12:02:30 +0200, Christof Thalhofer  
<chrisml at ...757...> a ?crit:

> Here is a good explanation of common git workflows:
> https://www.atlassian.com/git/tutorials/comparing-workflows
>
> Why do you want to develop in different versions at the same time, to
> fix bugs? Look at "Maintenance Branches" and "Hotfix", maybe that is,
> what you wanted to do?
>
> I am unsure what sort of development workflow would be the best for  
> Gambas.
>
> If I look at a big projekt for example that put its codebase to Git ?
> OTRS ? they did it so:
>
> https://github.com/OTRS/otrs
>
> Look there at the branches and tags. They seem to have ongoing
> development in master with branches for the "big" releases. Tags are
> used to point to subreleases.
>
>
> Alles Gute
>
> Christof Thalhofer

I took a bit of time to think about it, and I think the best workflow for
developing Gambas would be the one that's described in the Git  
documentation[0] :

- The master branch is the stable branch : it only contains the latest  
stable
   release of gambas. (with tags to keep the previous releases).
- A dev branch, for the development version. (the equivalent of the  
current trunk).
- Various branches for work-in-progress features that are not ready at all  
(like gb.term.form)

This way, we keep a workflow similar to the current one for bug fixes &  
minor changes
(we just commit to the dev branch).
For bigger changes and experimental components we create a new branch from  
the dev branch,
work on it, and then merge it back in the development branch when it's  
ready.
And when we want to release a new Gambas version, we just merge the  
development branch
in master, and create a tag to mark the new release.

If we need to make a patch release for bugfixes in the meantime, we can  
just use the master
branch to get back to the latest stable, and then make the fixes from  
there.
If the fix is already done on the development version, we can cherry-pick  
it from the dev
branch, and otherwise we can just make the fix on master (or on a  
temporary branch), and
then merge master back into the development branch.

This is also the workflow I use at work so maybe I'm too used to it and  
don't see
the downsides, but to me it seems to cover all of the use-cases.

[0] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows

-- 
Adrien Prokopowicz



From chrisml at ...757...  Fri Jul 28 17:06:41 2017
From: chrisml at ...757... (Christof Thalhofer)
Date: Fri, 28 Jul 2017 17:06:41 +0200
Subject: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)
In-Reply-To: <op.y33b5ujadlsaci@...102...>
References: <fb4f3865-2bf1-09a6-6363-db2bfdf63995@...1...>
 <1bda074c-b929-6377-bf49-d82ea33b2ef9@...1...>
 <dc6a5e55-6098-c328-048c-ff9973491581@...757...>
 <op.y33b5ujadlsaci@...102...>
Message-ID: <a1c94901-104d-db3c-3cf8-509eb7d99e1c@...757...>

Hi,

Am 28.07.2017 um 16:35 schrieb Adrien Prokopowicz:
> If we need to make a patch release for bugfixes in the meantime, we can  
> just use the master
> branch to get back to the latest stable, and then make the fixes from  
> there.
> If the fix is already done on the development version, we can cherry-pick  
> it from the dev
> branch, and otherwise we can just make the fix on master (or on a  
> temporary branch), and
> then merge master back into the development branch.
> 
> This is also the workflow I use at work so maybe I'm too used to it and  
> don't see
> the downsides, but to me it seems to cover all of the use-cases.
> 
> [0] https://git-scm.com/book/en/v2/Git-Branching-Branching-Workflows

Assume, Gambas gets bigger and more important and somewhere in the
future there exists a Gambas 3.20 in old distributions like Debian and
Gambas 4.05 in current Ubuntu, each of these versions is "stable".

Assume also there is a security breach introduced in Gambas 3.10 ;-)

How would you insert a hotfix which would lead to stable 3.21 and stable
4.06 in your model? IMO ... that would be impossible.


Alles Gute

Christof Thalhofer

-- 
Dies ist keine Signatur

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20170728/a3a20ba7/attachment.sig>

From taboege at ...176...  Fri Jul 28 17:20:18 2017
From: taboege at ...176... (Tobias Boege)
Date: Fri, 28 Jul 2017 17:20:18 +0200
Subject: [Gambas-devel] Gambas 3.10 - gb.web.feed
In-Reply-To: <f72fc1ce-3945-057b-57c9-837abab1a202@...1...>
References: <20170701194657.GC568@...756...>
 <28a5443e-28ac-c042-c57c-52dd2a817b72@...1...>
 <20170728135758.GF602@...756...>
 <f72fc1ce-3945-057b-57c9-837abab1a202@...1...>
Message-ID: <20170728152017.GG602@...756...>

On Fri, 28 Jul 2017, Beno?t Minisini via Gambas-devel wrote:
> > Yes, the timezone is mandatory there.
> > 
> > So, how about this: I make a class called RssDate where I store a UTC-based
> > timestamp (aka Date) and a timezone string. As I mentioned before, I think
> > the timezone string is necessary to let the user specify what timezone the
> > date will be printed in.
> > 
> > When an RFC822 date is read, I want to have its timezone string and the
> > timestamp of that date converted to UTC. When an RFC822 date is written,
> > I take the UTC timestamp and convert it to the string representation in
> > the timezone that the user wants to print the date in.
> > 
> > If that sounds reasonable, I can get to work now.
> > 
> > Regards,
> > Tobi
> > 
> 
> Why do you need the timezone part of the RFC822 date as a string? Why not
> just using Gambas Date and the Date.ToRFC822() / Date.FromRFC822()
> functions?
> 

When I read an RSS document into Rss objects, I want to retain the timezone
strings used in the original document. If I don't know the timezone string,
I would have to reset all timezones to UTC. The dates will be correct but
the timezone in the string representation of the date will have changed
(and the timezone may carry a meaning). It would be nice just to be able
to replicate a document that I have just read into gb.web.feed, too.

The attached script demonstrates two other problems:

  Print Date.ToRFC822(Date.FromRFC822("28 Jul 2017 08:00:00 GMT"), "GMT")
  >>Fri, 28 Jul 2017 4:0:0 GMT

First of all, the time components are not Format$(..., "00")'d, so they
print single digits where the RFC requires 2 digits. And second, shouldn't
reading a GMT date and putting it into GMT again result in the same string
that we started with? The 4 hour different is likely because I'm in +0200.

Regards,
Tobi

-- 
"There's an old saying: Don't change anything... ever!" -- Mr. Monk
-------------- next part --------------
#!/usr/bin/gbs3

Use "gb.util"

Public Sub Main()
  Print Date.ToRFC822(Date.FromRFC822("28 Jul 2017 08:00:00 GMT"), "GMT")
End

From adrien.prokopowicz at ...176...  Fri Jul 28 17:38:25 2017
From: adrien.prokopowicz at ...176... (Adrien Prokopowicz)
Date: Fri, 28 Jul 2017 17:38:25 +0200
Subject: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)
In-Reply-To: <a1c94901-104d-db3c-3cf8-509eb7d99e1c@...757...>
References: <fb4f3865-2bf1-09a6-6363-db2bfdf63995@...1...>
 <1bda074c-b929-6377-bf49-d82ea33b2ef9@...1...>
 <dc6a5e55-6098-c328-048c-ff9973491581@...757...>
 <op.y33b5ujadlsaci@...102...>
 <a1c94901-104d-db3c-3cf8-509eb7d99e1c@...757...>
Message-ID: <op.y33e2bivdlsaci@...102...>

Le Fri, 28 Jul 2017 17:06:41 +0200, Christof Thalhofer  
<chrisml at ...757...> a ?crit:

> Hi,
>
> Assume, Gambas gets bigger and more important and somewhere in the
> future there exists a Gambas 3.20 in old distributions like Debian and
> Gambas 4.05 in current Ubuntu, each of these versions is "stable".
>
> Assume also there is a security breach introduced in Gambas 3.10 ;-)
>
> How would you insert a hotfix which would lead to stable 3.21 and stable
> 4.06 in your model? IMO ... that would be impossible.
>
>
> Alles Gute
>
> Christof Thalhofer
>

You're right, I mistakingly assumed we would only have to maintain one  
stable
version (as it is the case right now).

However, I think the fix is pretty simple : we could add a legacy branch  
(branched
right before the 4.0 version would be merged into master, so it is still  
3.20), and
commit the fixes for the legacy version into it when needed (so we can  
release both
versions in parallel).

If the fix can be applied to both the legacy and stable versions without  
rewriting it
(unlikely, since the codebase would change a lot between these versions),  
then
cherry-picking the fixing commit into master should be enough. :-)

The model isn't set it stone. It's still Git, we can do whatever we want
whenever we want. Adding a few branches to our workflow later isn't a  
problem. ;-)

-- 
Adrien Prokopowicz



From mckaygerhard at ...176...  Fri Jul 28 18:03:37 2017
From: mckaygerhard at ...176... (PICCORO McKAY Lenz)
Date: Fri, 28 Jul 2017 12:03:37 -0400
Subject: [Gambas-devel] Fwd: Re: Gambas to Git(Lab) (Adrien Prokopowicz)
Message-ID: <CALci+FQiszTbgm0jJzn3+ghpdwo8H+mmdJJcv+-wkaJd4iM8Lw@...178...>

here i anwer the question made by Crist! and make some corrections to the
post of Adrien:

Date: Fri, 28 Jul 2017 16:35:44 +0200
> From: "Adrien Prokopowicz" <adrien.prokopowicz at ...176...>
> To: "mailing list for gambas developers"
>         <gambas-devel at lists.sourceforge.net>
> Subject: Re: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)
>

about that Adrien said:

> I took a bit of time to think about it, and I think the best workflow for
> developing Gambas would be the one that's described in the Git
> documentation[0] :
>
> - The master branch is the stable branch : it only contains the latest
> stable
>    release of gambas. (with tags to keep the previous releases).
> - A dev branch, for the development version. (the equivalent of the
> current trunk).
> - Various branches for work-in-progress features that are not ready at all
> (like gb.term.form)
>
its the most similar workflow, according to my git experience and svn
experience..
but please mantain a firm-name to the branches! like gb.xx.yy.dev

i mean added last word ".dev" at the end to enphasis the devel of that
componente, that due git can mantain history of the artifact..

the history of that branchs are important due must help to other developer
to see in the history how the problem are resolved in the time line..


>
> For bigger changes and experimental components we create a new branch from
> the dev branch,
> work on it, and then merge it back in the development branch when it's
> ready.
>
again in that case, the devel branch must named gambas3-devel and the
experimental gambas3-experimental

so gambas<X>-<type> where X are the mayor release, and tyope  the working
development branch type



> And when we want to release a new Gambas version, we just merge the
> development branch
> in master, and create a tag to mark the new release.
>
exactly!


>
> If we need to make a patch release for bugfixes in the meantime, we can
> just use the master
> branch to get back to the latest stable, and then make the fixes from
> there.
> If the fix is already done on the development version, we can cherry-pick
> it from the dev
> branch, and otherwise we can just make the fix on master (or on a
> temporary branch), and
> then merge master back into the development branch.
>
its almost like but works


but WAITH STILL NEED ENTION MERGE AND PULL PATCHES FROM USERS its important!
this anwers the question made by Cris, lest see:


> From: Christof Thalhofer <chrisml at ...757...>
> To: mailing list for gambas developers
>         <gambas-devel at lists.sourceforge.net>
> Subject: Re: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)
> Message-ID: <a1c94901-104d-db3c-3cf8-509eb7d99e1c at ...757...>
> Content-Type: text/plain; charset="utf-8"
>
> Hi,
> Assume, Gambas gets bigger and more important and somewhere in the
> future there exists a Gambas 3.20 in old distributions like Debian and
> Gambas 4.05 in current Ubuntu, each of these versions is "stable".
>
> Assume also there is a security breach introduced in Gambas 3.10 ;-)
>
> How would you insert a hotfix which would lead to stable 3.21 and stable
> 4.06 in your model? IMO ... that would be impossible.
>


but WAITH STILL NEED ENTION MERGE AND PULL PATCHES FROM USERS its important!

that feature are not present in the svn, due the svn are limited to
developers of the gambas repository.. how will be that?

well in github/gitlab, there's a feature that limits the pull request and
merge request to the already commiters!
users can request also joint to propose a pull reques..

if you guys dont do that, maybe the pull repo will be like the codeigniter
or like the owncloud, a large pull request of issues..
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20170728/26ac7e34/attachment.html>

From adrien.prokopowicz at ...176...  Fri Jul 28 21:24:35 2017
From: adrien.prokopowicz at ...176... (Adrien Prokopowicz)
Date: Fri, 28 Jul 2017 21:24:35 +0200
Subject: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)
In-Reply-To: <CALci+FQiszTbgm0jJzn3+ghpdwo8H+mmdJJcv+-wkaJd4iM8Lw@...178...>
References: <CALci+FQiszTbgm0jJzn3+ghpdwo8H+mmdJJcv+-wkaJd4iM8Lw@...178...>
Message-ID: <op.y33pi9frdlsaci@...102...>

Le Fri, 28 Jul 2017 18:03:37 +0200, PICCORO McKAY Lenz  
<mckaygerhard at ...176...> a ?crit:

> but please mantain a firm-name to the branches! like gb.xx.yy.dev
> i mean added last word ".dev" at the end to enphasis the devel of that  
> componente, that due git can mantain history of >the artifact..
> the history of that branchs are important due must help to other  
> developer to see in the history how the problem are >resolved in the  
> time line..

You mean adding ".dev" to help seeing this is an in-development branch ?  
Because
Git does not care what your branches are named (besides master), so I  
don't see
how it helps Git "maintain history"?

Also, you have to see the experimental branches as temporary ones. When  
you are done
with your feature, you get it merged into the development branch (without  
squashing
the commits of course !), and then you delete the branch.

 From experience, I can say that you do not want old branches laying around  
or it will
become an huge mess in no time. Moreover, in the rare case you want to  
consult the
history, looking at the file/directory's history is easier than looking  
for the history
of a branch. So there is no point in keeping them, at least for our case.

> again in that case, the devel branch must named gambas3-devel and the  
> experimental gambas3-experimental
>
> so gambas<X>-<type> where X are the mayor release, and tyope  the  
> working development branch type

There wouldn't be an "experimental" branch, but one for each non-ready  
feature.

> this anwers the question made by Cris, lest see:
>but WAITH STILL NEED ENTION MERGE AND PULL PATCHES FROM USERS its  
> important!

No caps needed there, it's not the end of the world.

With this workflow, user-submitted merge requests (or pull requests in  
GitHub terminology)
are managed just like with the "internal" experimental branches.

The user just has to fork the repository to its own, branch from the  
development
version, work on their own branch, then submit a merge request to merge  
their
branch back in the development version. If the code is approved, then it  
gets
merged and done. :)

> well in github/gitlab, there's a feature that limits the pull request  
> and merge request to the already commiters!
> users can request also joint to propose a pull reques..
>
> if you guys dont do that, maybe the pull repo will be like the  
> codeigniter or like the owncloud, a large pull request of >issues..

I'm not sure I understand, you're afraid that there may be too many pull  
requests ?
First, I think this if a false problem. Not only contributions are very  
welcome,
but both GitLab and GitHub provide tools to handle big amounts of pull  
requests.

An example of project with lots of contributions is Rust[0] : they've got  
like 20
pull requests in the last 7 days (not counting the closed ones), and  
because they
properly tagged everything, I know what every pull request needs, and from  
who, even
if I have no idea what they actually are about.

Also, making users ask permission to open merge requests make no sense at  
all.
A merge request (as its name implies) is already a request from an user to  
merge
code in the main repository (with code review from the maintainers). So  
they would
have to make a request to make a request to merge code ? :-)

[0] https://github.com/rust-lang/rust/pulls
-- 
Adrien Prokopowicz



From adrien.prokopowicz at ...176...  Fri Jul 28 21:51:05 2017
From: adrien.prokopowicz at ...176... (Adrien Prokopowicz)
Date: Fri, 28 Jul 2017 21:51:05 +0200
Subject: [Gambas-devel] Arrays memory layout
Message-ID: <op.y33qrf2cdlsaci@...102...>

Hi folks, I have a little question about Gambas Arrays in native  
components.

In order to get/put data, according to the docs[0] the only way I have is  
to call
Array.Get() to retrieve a pointer to the given index.

But since calling this for every index could be pretty slow, I was  
wondering if I could
consider the pointer returned by Array.Get(0) to be the start of a  
continuous memory
block of the size of the array, so I could directly access it (and use  
memcpy and such) ?

Having read the source code and tested a bit I think this is safe, but  
since the array
type is opaque and there is no other exposed method than Get(), I would  
like to be
sure there is no hidden shenanigan going on. :-)

Regards,

[0] http://gambaswiki.org/wiki/dev/api/cat/array

-- 
Adrien Prokopowicz



From gambas at ...1...  Fri Jul 28 21:57:56 2017
From: gambas at ...1... (=?UTF-8?Q?Beno=c3=aet_Minisini?=)
Date: Fri, 28 Jul 2017 21:57:56 +0200
Subject: [Gambas-devel] Arrays memory layout
In-Reply-To: <op.y33qrf2cdlsaci@...102...>
References: <op.y33qrf2cdlsaci@...102...>
Message-ID: <b953ada9-0aa8-befc-ad9e-d40c14cc6226@...1...>

Le 28/07/2017 ? 21:51, Adrien Prokopowicz a ?crit :
> Hi folks, I have a little question about Gambas Arrays in native 
> components.
> 
> In order to get/put data, according to the docs[0] the only way I have 
> is to call
> Array.Get() to retrieve a pointer to the given index.
> 
> But since calling this for every index could be pretty slow, I was 
> wondering if I could
> consider the pointer returned by Array.Get(0) to be the start of a 
> continuous memory
> block of the size of the array, so I could directly access it (and use 
> memcpy and such) ?
> 
> Having read the source code and tested a bit I think this is safe, but 
> since the array
> type is opaque and there is no other exposed method than Get(), I would 
> like to be
> sure there is no hidden shenanigan going on. :-)
> 
> Regards,
> 
> [0] http://gambaswiki.org/wiki/dev/api/cat/array
> 

Yes you can, provided that :

- You correctly cast the void pointer returned by Array.Get(0).

- You understand that this pointer is valid until you add ore remove 
elements.

Regards,

-- 
Beno?t Minisini



From adrien.prokopowicz at ...176...  Fri Jul 28 22:04:34 2017
From: adrien.prokopowicz at ...176... (Adrien Prokopowicz)
Date: Fri, 28 Jul 2017 22:04:34 +0200
Subject: [Gambas-devel] Arrays memory layout
In-Reply-To: <b953ada9-0aa8-befc-ad9e-d40c14cc6226@...1...>
References: <op.y33qrf2cdlsaci@...102...>
 <b953ada9-0aa8-befc-ad9e-d40c14cc6226@...1...>
Message-ID: <op.y33rdwngdlsaci@...102...>

Le Fri, 28 Jul 2017 21:57:56 +0200, Beno?t Minisini  
<gambas at ...1...> a ?crit:

> Le 28/07/2017 ? 21:51, Adrien Prokopowicz a ?crit :
>> Hi folks, I have a little question about Gambas Arrays in native  
>> components.
>>  In order to get/put data, according to the docs[0] the only way I have  
>> is to call
>> Array.Get() to retrieve a pointer to the given index.
>>  But since calling this for every index could be pretty slow, I was  
>> wondering if I could
>> consider the pointer returned by Array.Get(0) to be the start of a  
>> continuous memory
>> block of the size of the array, so I could directly access it (and use  
>> memcpy and such) ?
>>  Having read the source code and tested a bit I think this is safe, but  
>> since the array
>> type is opaque and there is no other exposed method than Get(), I would  
>> like to be
>> sure there is no hidden shenanigan going on. :-)
>>  Regards,
>>  [0] http://gambaswiki.org/wiki/dev/api/cat/array
>>
>
> Yes you can, provided that :
>
> - You correctly cast the void pointer returned by Array.Get(0).
>
> - You understand that this pointer is valid until you add ore remove  
> elements.
>
> Regards,
>

Okay, thanks for the confirmation ! :)
I'll probably add this to the wiki when i have some time, since this can be
quite useful.

Regards,
-- 
Adrien Prokopowicz



From chrisml at ...757...  Fri Jul 28 22:11:10 2017
From: chrisml at ...757... (Christof Thalhofer)
Date: Fri, 28 Jul 2017 22:11:10 +0200
Subject: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)
In-Reply-To: <op.y33e2bivdlsaci@...102...>
References: <fb4f3865-2bf1-09a6-6363-db2bfdf63995@...1...>
 <1bda074c-b929-6377-bf49-d82ea33b2ef9@...1...>
 <dc6a5e55-6098-c328-048c-ff9973491581@...757...>
 <op.y33b5ujadlsaci@...102...>
 <a1c94901-104d-db3c-3cf8-509eb7d99e1c@...757...>
 <op.y33e2bivdlsaci@...102...>
Message-ID: <fc530fdd-a1da-9e28-7402-86b6ddcb4008@...757...>

Am 28.07.2017 um 17:38 schrieb Adrien Prokopowicz:

> You're right, I mistakingly assumed we would only have to maintain one  
> stable
> version (as it is the case right now).
> 
> However, I think the fix is pretty simple : we could add a legacy branch  
> (branched
> right before the 4.0 version would be merged into master, so it is still  
> 3.20), and
> commit the fixes for the legacy version into it when needed (so we can  
> release both
> versions in parallel).

Yes. Ok, I see, so:

                               .--------------.
                             ^ | Branch: 3.21 |----->
                            /  '--------------'
.--------.      .-----------.                 .-----------.
| Master |----->| Tag: 3.20 |------......---->| Tag: 4.05 |
'--------'      '-----------'                 '-----------'

Right?

> If the fix can be applied to both the legacy and stable versions without  
> rewriting it
> (unlikely, since the codebase would change a lot between these versions),  
> then
> cherry-picking the fixing commit into master should be enough. :-)

Yes.

> The model isn't set it stone. It's still Git, we can do whatever we want
> whenever we want. Adding a few branches to our workflow later isn't a  
> problem. ;-)

Also Yes :-)


Alles Gute

Christof Thalhofer

-- 
Dies ist keine Signatur

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.gambas-basic.org/pipermail/devel/attachments/20170728/a1ae2050/attachment.sig>

From adrien.prokopowicz at ...176...  Fri Jul 28 22:17:02 2017
From: adrien.prokopowicz at ...176... (Adrien Prokopowicz)
Date: Fri, 28 Jul 2017 22:17:02 +0200
Subject: [Gambas-devel] Fwd: Re: Gambas to Git(Lab)
In-Reply-To: <fc530fdd-a1da-9e28-7402-86b6ddcb4008@...757...>
References: <fb4f3865-2bf1-09a6-6363-db2bfdf63995@...1...>
 <1bda074c-b929-6377-bf49-d82ea33b2ef9@...1...>
 <dc6a5e55-6098-c328-048c-ff9973491581@...757...>
 <op.y33b5ujadlsaci@...102...>
 <a1c94901-104d-db3c-3cf8-509eb7d99e1c@...757...>
 <op.y33e2bivdlsaci@...102...>
 <fc530fdd-a1da-9e28-7402-86b6ddcb4008@...757...>
Message-ID: <op.y33ryoi4dlsaci@...102...>

Le Fri, 28 Jul 2017 22:11:10 +0200, Christof Thalhofer  
<chrisml at ...757...> a ?crit:

> Am 28.07.2017 um 17:38 schrieb Adrien Prokopowicz:
>
>> You're right, I mistakingly assumed we would only have to maintain one
>> stable
>> version (as it is the case right now).
>>
>> However, I think the fix is pretty simple : we could add a legacy branch
>> (branched
>> right before the 4.0 version would be merged into master, so it is still
>> 3.20), and
>> commit the fixes for the legacy version into it when needed (so we can
>> release both
>> versions in parallel).
>
> Yes. Ok, I see, so:
>
>                                .--------------.
>                              ^ | Branch: 3.21 |----->
>                             /  '--------------'
> .--------.      .-----------.                 .-----------.
> | Master |----->| Tag: 3.20 |------......---->| Tag: 4.05 |
> '--------'      '-----------'                 '-----------'
>
> Right?

Yes, that's exactly it. :)

-- 
Adrien Prokopowicz