On 29/03/14 07:04, Luca Delucchi wrote:
Hi PSC,
with the upcoming GRASS 7 release we have to many branches to maintain
(releasebranch6, devbranch6, releasebranch7 and trunk).
Can I ask you to take a decision about the future of all this branches?
I could suggest something like:
- keep
Dear PSC,
2014-03-31 4:30 GMT+02:00 Yann Chemin yche...@gmail.com:
+1 to remove devbranch6 after appropriate transfer of the needed to
releasebranch6.
same here +1, maybe not to remove, just to set as read only
Do we have a tentative time line to freeze Grass6 release branch (1 year?)
You
On Mon, Mar 31, 2014 at 4:30 AM, Yann Chemin yche...@gmail.com wrote:
In favour of giving the devbranch6 a prune, I cannot remember when I used
grass6-dev last time...
Obviously will maintain GRASS 6.4.x for more time, that's our LTS...
+1 to remove devbranch6 after appropriate transfer of
On Mon, Mar 31, 2014 at 10:24 AM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
The initial idea was to create a tech-preview release of grass7, not an
official 7.0 release. Has that changed during the sprint ?
No, this is what happened: beta1 (called like this to maintain
consistency with
On 29/03/14 21:56, Vaclav Petras wrote:
Inspired by what code sprint people were saying, I put together my
proposal. It counts with release once a year and a half year bugfixing
(feature freeze) period before the release. I expect comments and
criticism and I would be glad to compare this
On 31/03/14 10:34, Markus Neteler wrote:
On Mon, Mar 31, 2014 at 10:24 AM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
The initial idea was to create a tech-preview release of grass7, not an
official 7.0 release. Has that changed during the sprint ?
No, this is what happened: beta1
Hi Vasek,
your proposal is identical to my opinion. Taking into account number of
developers of GRASS GIS, the proposal seems to me as best solution to avoid
recurrence of current state when GRASS 7 has become used as stable by many
users as consequence of many years of development
On Mon, Mar 31, 2014 at 4:35 AM, Moritz Lennert
mlenn...@club.worldonline.be wrote:
On 29/03/14 21:56, Vaclav Petras wrote:
Inspired by what code sprint people were saying, I put together my
proposal. It counts with release once a year and a half year bugfixing
(feature freeze) period
PSC,
we have received a donation from a company where the donor expected to
be listed at
http://grass.osgeo.org/support/our-sponsors/
We (Martin and me) assumed that they donated for the Vienna Sprint
(list of donors is on the Wiki page) but they expect to be mentioned
on the main site.
Since
Hi all,
2014-03-31 20:07 GMT+02:00 Luca Delucchi lucadel...@gmail.com:
On 31 March 2014 17:40, Vaclav Petras wenzesl...@gmail.com wrote:
First, the lengths of time periods. First question is how often we want to
release MAJOR.MINOR version. Once a year looks good for me but I have no
special
It looks like we all want to see version numbers move on a yearly basis
with periods of branching and periods of releasing...
Should we finalize this policy and implement it?
On 31 March 2014 23:54, Martin Landa landa.mar...@gmail.com wrote:
Hi all,
2014-03-31 20:07 GMT+02:00 Luca
11 matches
Mail list logo