Done
Jacques
Le 01/04/2015 15:42, Jacopo Cappellato a écrit :
On Apr 1, 2015, at 3:30 PM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:
That sounds good to me, I agree it's more complete and less disturbing than my
proposition, not sure about strongly
Jacques
I agree with Jacques:
It adds unnecessary uncertainty. How do we even know if a particular bug
exists in older releases? Users can find known unresolved bugs for their
version in jira.
Regards
Scott
On 31 Mar 2015 00:38, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:
So what would you suggest? To put one more
So you suggest we say anything?
Jacques
Le 01/04/2015 14:09, Scott Gray a écrit :
It adds unnecessary uncertainty. How do we even know if a particular bug
exists in older releases? Users can find known unresolved bugs for their
version in jira.
Regards
Scott
On 31 Mar 2015 00:38, Jacques Le
Le 01/04/2015 14:15, Jacques Le Roux a écrit :
So you suggest we say anything?
I meant nothing
On Apr 1, 2015, at 2:17 PM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:
Le 01/04/2015 14:15, Jacques Le Roux a écrit :
So you suggest we say anything?
I meant nothing
Yeah.
Or, if you really want to add something, I would rather use a text similar to
what Adrian and Pierre
+1
I agree the original version sounded a bit negative.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 4/1/2015 2:01 PM, Sharan Foga wrote:
Hi All
My suggestion would be:
Despite our best efforts to maintain up to three active release
branches, support for older branches can
On Apr 1, 2015, at 3:30 PM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:
That sounds good to me, I agree it's more complete and less disturbing than
my proposition, not sure about strongly
Jacques
I agree with Jacques: maybe we can drop the strongly word: recommend is
already
Hi All
My suggestion would be:
Despite our best efforts to maintain up to three active release
branches, support for older branches can decrease because our project
volunteers may be focussed on other issues. We strongly recommend using
releases from the most recent branch wherever possible
+1
thank you Sharan.
Jacopo
On Apr 1, 2015, at 3:01 PM, Sharan Foga sharan.f...@gmail.com wrote:
Hi All
My suggestion would be:
Despite our best efforts to maintain up to three active release branches,
support for older branches can decrease because our project volunteers may be
That sounds good to me, I agree it's more complete and less disturbing than my
proposition, not sure about strongly
Jacques
Le 01/04/2015 15:01, Sharan Foga a écrit :
Hi All
My suggestion would be:
Despite our best efforts to maintain up to three active release branches, support for older
I propose to use the last sentence I suggested and to add a link to the wiki
where we explain that, OK?
Jacques
Le 24/03/2015 18:08, Jacopo Cappellato a écrit :
On Mar 24, 2015, at 2:28 PM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:
I did not meant to ask our users to backport bug
So what would you suggest? To put one more sentence in the download page to
explain what you mentioned below?
jacques
Le 30/03/2015 13:22, Jacopo Cappellato a écrit :
My preference is to have a download the page clean and well written without
links to external wiki, unless really required.
My preference is to have a download the page clean and well written without
links to external wiki, unless really required.
Jacopo
On Mar 30, 2015, at 11:42 AM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:
I propose to use the last sentence I suggested and to add a link to the wiki
+1 for statement of Jacques. And it should also be stated on our 'release
policy' page.
Clear, unambiguous messages ensure that we tell a consistent story. Not
only to potential adopters but they also remind of what we do, for whom and
how. Having those up front helps us to have long, winding
My advise is somewhat similar: 'Once a release branch is created, support
for older releases can decrease - because volunteers tend to focus their
efforts on issues that hold their interest more.'
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing,
Jacopo, Adrian,
Why do you see a problem with this sentence there? It seems the best place to inform our users, no? There are more chances to be seen than somewhere
in the wiki.
Maybe I did not write it right because I tried to be brief?
I did not meant to ask our users to backport bug fixes
'Helps us to avoid long, winding threads in our mailing lists' was what I
wanted to bring across.
Best regards,
Pierre Smits
*ORRTIZ.COM http://www.orrtiz.com*
Services Solutions for Cloud-
Based Manufacturing, Professional
Services and Retail Trade
http://www.orrtiz.com
On Tue, Mar 24, 2015
I agree. Something like that belongs on the wiki.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 3/24/2015 10:41 AM, Jacopo Cappellato wrote:
In the download page we should also strive to have a more formal language:
maybe Sharan, Adrian or others that are fluent with English
I usually give my clients this advice:
Once a release branch is created, support for previous releases
decreases - because volunteers tend to focus their efforts on more
recent releases.
Maybe that will help.
Adrian Crum
Sandglass Software
www.sandglass-software.com
On 3/24/2015 11:33 AM,
On Mar 24, 2015, at 2:28 PM, Jacques Le Roux jacques.le.r...@les7arts.com
wrote:
I did not meant to ask our users to backport bug fixes themselves, only when
a bug miss in a release and they need it.
If they need it, and they have the ability to create a backport, then they
should be
20 matches
Mail list logo
