From rubyforge at lokorin.org  Tue Mar 17 15:09:52 2009
From: rubyforge at lokorin.org (Andreas Launila)
Date: Tue, 17 Mar 2009 20:09:52 +0100
Subject: [gecoder-devel] Gecode 3.0
Message-ID: <49BFF580.7020502@lokorin.org>

Gecode 3.0 was released Friday the 13th.

At first glance, the changes that affect Gecode/R seem to be mostly
changes to the interface[1]. I.e. there are no major new features that
have to be implemented on the Ruby side.

The steps will be something along the line of:
1. Make the specs pass again.
2. Add support for the minor additions, such as the new branching 	
   strategies.
3. Update the website.
The work will be done in /branches/gecode-3.0

One question is whether the 3.0-compatible version of Gecode/R should be
called Gecode/R 3.0.0 or Gecode/R 1.1.0 . The former makes it clearer
what Gecode version it requires, but is somewhat confusing (there is no
Gecode/R 2.*). Additionally, the latter means that Gecode/R would more
or less commit to following Gecode's release numbering, causing a
headache when Gecode/R releases a new version that is not spurred by a
new Gecode release. Hence I would go for Gecode/R 1.1.0 .

[1]
http://www.gecode.org/doc-latest/reference/PageChange.html#SectionChanges_3_0_0

-- 
Andreas Launila

From zayenz at gmail.com  Wed Mar 18 02:36:30 2009
From: zayenz at gmail.com (Mikael Zayenz Lagerkvist)
Date: Wed, 18 Mar 2009 07:36:30 +0100
Subject: [gecoder-devel] Gecode 3.0
In-Reply-To: <49BFF580.7020502@lokorin.org>
References: <49BFF580.7020502@lokorin.org>
Message-ID: <63b5c8b00903172336g1c90860fn7112906f647c8a04@mail.gmail.com>

Hi,

On Tue, Mar 17, 2009 at 8:09 PM, Andreas Launila <rubyforge at lokorin.org> wrote:
> 2. Add support for the minor additions, such as the new branching
>   strategies.

The new branching strategies with tie breaking are probably the most
interesting feature-change for Gecode/R. For interfacing the biggest
change is that most parameters are now passed as references instead of
pointers.


> One question is whether the 3.0-compatible version of Gecode/R should be
> called Gecode/R 3.0.0 or Gecode/R 1.1.0 . The former makes it clearer
> what Gecode version it requires, but is somewhat confusing (there is no
> Gecode/R 2.*). Additionally, the latter means that Gecode/R would more
> or less commit to following Gecode's release numbering, causing a
> headache when Gecode/R releases a new version that is not spurred by a
> new Gecode release. Hence I would go for Gecode/R 1.1.0 .

I thought I could give some additional input on this, when developing
Gecode/J and Gecode/FlatZinc we have had the same problem with version
numbering.

For Gecode/J we decided on a synchronized version numbering since
there was no real development done aside from tracking the changes in
Gecode. This is no longer relevant since Gecode/J has been
discontinued however. For Gecode/FlatZinc the version numbering is
independent of the Gecode version numbering. This has to do with the
fact that Gecode/FlatZinc needs to follow the specification of
FlatZinc which is not (naturally) synchronized with Gecode releases.

In other words, I concur that a stand-alone version numbering for
Gecode/R would be the best choice, the reason being that there is
independent development of the system that is not only concerned with
tracking Gecode changes.

Cheers,
Mikael

-- 
Mikael Zayenz Lagerkvist, http://www.ict.kth.se/~zayenz/