You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Max Bowsher <ma...@ukf.net> on 2007/09/26 21:18:47 UTC
SWIG versions - why not 1.3.31 yet?
Does anyone know why our SWIG upper bound is still set at 1.3.29? Is
there any reason not to increase to 1.3.31?
Meanwhile, should we be taking this opportunity to increase the lower
bound? I don't imagine anyone's making a habit of testing new binding
development across the entire range, and I seem to remember SWIG 1.3.24
-> .25 being a significant change.
Max.
Re: SWIG versions - why not 1.3.31 yet?
Posted by Max Bowsher <ma...@ukf.net>.
Dan Christian wrote:
> The Ubuntu long term support release (dapper) still ships with swig
> 1.3.27. It would be a (needless) pain if that was no longer
> supported. Not everyone updates there OS every 6 months or enjoys
> building swig from scratch.
>
> Given that only developers are affected, what does it mean to "drop
> support"? How much support effort will this really save?
A local swig installation *not* required to build the bindings from a
release tarball. It's only needed to build them from a checkout, or to
regenerate files which are shipped in the tarball.
*** Therefore only people developing Subversion, or deliberately
choosing to rebuild the generated SWIG files despite pregenerated ones
being shipped in the tarball, are affected. ***
Dropping support for older versions of swig saves a *lot* of effort,
since SWIG tends to undergo significant changes - restricting the
allowed versions cuts down the number of different interpretations of
the mappings that developers have to think about.
Max.
Re: SWIG versions - why not 1.3.31 yet?
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Fri, 28 Sep 2007, Ben Collins-Sussman wrote:
> On 9/27/07, Max Bowsher <ma...@ukf.net> wrote:
>
>> Users of enterprise, slow-update-cycle, distros should be using
>> Subversion release tarballs, not svn checkouts, and thereby be unaffected.
>
> To be utterly clear: from the user's point of view, there is no
> compile-time or run-time dependency on any particular version of swig.
> The svn release tarball ships with bindings that are
> ready-to-compile, with no external dependencies.
>
> So it's irrelevant what version of swig happens to ship in any
> particular linux distro. The *only* people who need a certain version
> of swig available are svn developers building from a working copy.
>
OK, that makes sense. Thanks.
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = 0B44 B118 85CC F4EC 7021 1ED4 1516 5B78 E320 2001
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SWIG versions - why not 1.3.31 yet?
Posted by Max Bowsher <ma...@ukf.net>.
Daniel L. Rall wrote:
> On Fri, 28 Sep 2007, Max Bowsher wrote:
>> Dan Christian wrote:
>>>
>>> It's just that many developers use the same slow release distros as
>>> the users (its called a "day job" :-). So touching the swig bindings
>>> (with a 1.3.31 requirement) means building and installing swig from
>>> scratch.
>> ./configure
>> make
>> make install
>>
>> done.
> Max, Dan was referring to actually *changing* the SWIG bindings, which
> requires SWIG and autogen.sh. He may be doing this as part of $day_job,
> and tied to a specific platform where a more recent version of SWIG
> isn't readily available, and must be custom-built.
Yes - sorry I was unclear - I was attempting to point out (in a rather
overly terse way) that building SWIG is utterly trivial, just
./configure && make && make install, so the people having to do so is a
very minor inconvenience, if at all.
Max.
Re: SWIG versions - why not 1.3.31 yet?
Posted by "Daniel L. Rall" <dl...@finemaltcoding.com>.
On Fri, 28 Sep 2007, Max Bowsher wrote:
> Dan Christian wrote:
> > On 9/28/07, Ben Collins-Sussman wrote:
> >> To be utterly clear: from the user's point of view, there is no
> >> compile-time or run-time dependency on any particular version of swig.
> >> The svn release tarball ships with bindings that are
> >> ready-to-compile, with no external dependencies.
> >>
> >> So it's irrelevant what version of swig happens to ship in any
> >> particular linux distro. The *only* people who need a certain version
> >> of swig available are svn developers building from a working copy.
> >
> > It was always clear that SWIG was optional for users and developers
> > who don't touch the bindings.
> >
> > It's just that many developers use the same slow release distros as
> > the users (its called a "day job" :-). So touching the swig bindings
> > (with a 1.3.31 requirement) means building and installing swig from
> > scratch.
>
> ./configure
> make
> make install
>
> done.
Max, Dan was referring to actually *changing* the SWIG bindings, which
requires SWIG and autogen.sh. He may be doing this as part of $day_job,
and tied to a specific platform where a more recent version of SWIG
isn't readily available, and must be custom-built.
> > Which is fine if you get something for it. So far, no one has said
> > what is the gain is of requiring 1.3.31 instead of 1.3.27. There were
> > comments that 1.3.25 was a bit change, but nothing more specific than
> > that.
>
> * Discarding compatibility code.
> * Developers not having to think about differences across a broad range
> of versions.
> * Developers not having to *TEST* so many versions.
>
> > I'm just trying to keep the developer barrier to entry as low as is
> > practical ('cause it might make my life easier :-).
>
> Weigh the possible need for a new developer to download swig and run
> "./configure && make && make install" against the expectation of
> producing patches which are functional across a broad range of swig
> versions - I think it's justifiable to say that tightening up the
> allowed version range actually lowers the real developer barrier a bit.
Me too, though perhaps not going so far as dropping all but the most
recent version.
--
Daniel Rall
Re: SWIG versions - why not 1.3.31 yet?
Posted by Max Bowsher <ma...@ukf.net>.
Dan Christian wrote:
> On 9/28/07, Ben Collins-Sussman wrote:
>> To be utterly clear: from the user's point of view, there is no
>> compile-time or run-time dependency on any particular version of swig.
>> The svn release tarball ships with bindings that are
>> ready-to-compile, with no external dependencies.
>>
>> So it's irrelevant what version of swig happens to ship in any
>> particular linux distro. The *only* people who need a certain version
>> of swig available are svn developers building from a working copy.
>
> It was always clear that SWIG was optional for users and developers
> who don't touch the bindings.
>
> It's just that many developers use the same slow release distros as
> the users (its called a "day job" :-). So touching the swig bindings
> (with a 1.3.31 requirement) means building and installing swig from
> scratch.
./configure
make
make install
done.
> Which is fine if you get something for it. So far, no one has said
> what is the gain is of requiring 1.3.31 instead of 1.3.27. There were
> comments that 1.3.25 was a bit change, but nothing more specific than
> that.
* Discarding compatibility code.
* Developers not having to think about differences across a broad range
of versions.
* Developers not having to *TEST* so many versions.
> I'm just trying to keep the developer barrier to entry as low as is
> practical ('cause it might make my life easier :-).
Weigh the possible need for a new developer to download swig and run
"./configure && make && make install" against the expectation of
producing patches which are functional across a broad range of swig
versions - I think it's justifiable to say that tightening up the
allowed version range actually lowers the real developer barrier a bit.
Max.
Re: SWIG versions - why not 1.3.31 yet?
Posted by Dan Christian <dc...@google.com>.
On 9/28/07, Ben Collins-Sussman <su...@red-bean.com> wrote:
> On 9/27/07, Max Bowsher <ma...@ukf.net> wrote:
>
> > Users of enterprise, slow-update-cycle, distros should be using
> > Subversion release tarballs, not svn checkouts, and thereby be unaffected.
>
> To be utterly clear: from the user's point of view, there is no
> compile-time or run-time dependency on any particular version of swig.
> The svn release tarball ships with bindings that are
> ready-to-compile, with no external dependencies.
>
> So it's irrelevant what version of swig happens to ship in any
> particular linux distro. The *only* people who need a certain version
> of swig available are svn developers building from a working copy.
It was always clear that SWIG was optional for users and developers
who don't touch the bindings.
It's just that many developers use the same slow release distros as
the users (its called a "day job" :-). So touching the swig bindings
(with a 1.3.31 requirement) means building and installing swig from
scratch.
Which is fine if you get something for it. So far, no one has said
what is the gain is of requiring 1.3.31 instead of 1.3.27. There were
comments that 1.3.25 was a bit change, but nothing more specific than
that.
Ubuntu 6.06 LTS (dapper) has 1.3.27
Ubuntu 6.10 (edgy) has 1.3.28
Ubuntu 7.04 (fiesty) has 1.3.31
I'm just trying to keep the developer barrier to entry as low as is
practical ('cause it might make my life easier :-).
-Dan C
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SWIG versions - why not 1.3.31 yet?
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 9/27/07, Max Bowsher <ma...@ukf.net> wrote:
> Users of enterprise, slow-update-cycle, distros should be using
> Subversion release tarballs, not svn checkouts, and thereby be unaffected.
To be utterly clear: from the user's point of view, there is no
compile-time or run-time dependency on any particular version of swig.
The svn release tarball ships with bindings that are
ready-to-compile, with no external dependencies.
So it's irrelevant what version of swig happens to ship in any
particular linux distro. The *only* people who need a certain version
of swig available are svn developers building from a working copy.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SWIG versions - why not 1.3.31 yet?
Posted by Max Bowsher <ma...@ukf.net>.
David Summers wrote:
>
> On Wed, 26 Sep 2007, Dan Christian wrote:
>
>> The Ubuntu long term support release (dapper) still ships with swig
>> 1.3.27. It would be a (needless) pain if that was no longer
>> supported. Not everyone updates there OS every 6 months or enjoys
>> building swig from scratch.
>>
>> Given that only developers are affected, what does it mean to "drop
>> support"? How much support effort will this really save?
>>
>> -Dan C
>>
>
> Same reasoning for RedHat Enterprise Linux. Normally a new version only
> comes out every 18 - 24 months. If it is not a problem to support older
> versions (unless some overriding reason like security or bad bugs) it
> would be nice to still support older versions of supporting libs.
Same counter-reasoning as in my previous message.
Users of enterprise, slow-update-cycle, distros should be using
Subversion release tarballs, not svn checkouts, and thereby be unaffected.
Max.
Re: SWIG versions - why not 1.3.31 yet?
Posted by David Summers <da...@summersoft.fay.ar.us>.
On Wed, 26 Sep 2007, Dan Christian wrote:
> The Ubuntu long term support release (dapper) still ships with swig
> 1.3.27. It would be a (needless) pain if that was no longer
> supported. Not everyone updates there OS every 6 months or enjoys
> building swig from scratch.
>
> Given that only developers are affected, what does it mean to "drop
> support"? How much support effort will this really save?
>
> -Dan C
>
Same reasoning for RedHat Enterprise Linux. Normally a new version only
comes out every 18 - 24 months. If it is not a problem to support older
versions (unless some overriding reason like security or bad bugs) it
would be nice to still support older versions of supporting libs.
> On 9/26/07, Max Bowsher <ma...@ukf.net> wrote:
>> (1) Since 1.3.31 was released 10 months ago, it would be unreasonable
>> not to support it if it is feasible to do so.
>>
>> (2) Given that SWIG is not required to build the bindings from a
>> release, only to do development on them, or to be a release manager, I
>> see no reason to support versions more than one year old, if even that
>> much. If we adopted that policy, we would drop support for all versions
>> prior to 1.3.29 immediately, and in two months time, drop support for
>> all versions prior to 1.3.31. Or, we could just go ahead and drop
>> support for all versions prior to 1.3.31 right now.
>>
>>
>> Max.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
David Wayne Summers "Linux: Because reboots are for hardware upgrades!"
david@summersoft.fay.ar.us PGP Key: http://summersoft.fay.ar.us/~david/pgp.txt
PGP Key fingerprint = 0B44 B118 85CC F4EC 7021 1ED4 1516 5B78 E320 2001
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SWIG versions - why not 1.3.31 yet?
Posted by Dan Christian <dc...@google.com>.
The Ubuntu long term support release (dapper) still ships with swig
1.3.27. It would be a (needless) pain if that was no longer
supported. Not everyone updates there OS every 6 months or enjoys
building swig from scratch.
Given that only developers are affected, what does it mean to "drop
support"? How much support effort will this really save?
-Dan C
On 9/26/07, Max Bowsher <ma...@ukf.net> wrote:
> (1) Since 1.3.31 was released 10 months ago, it would be unreasonable
> not to support it if it is feasible to do so.
>
> (2) Given that SWIG is not required to build the bindings from a
> release, only to do development on them, or to be a release manager, I
> see no reason to support versions more than one year old, if even that
> much. If we adopted that policy, we would drop support for all versions
> prior to 1.3.29 immediately, and in two months time, drop support for
> all versions prior to 1.3.31. Or, we could just go ahead and drop
> support for all versions prior to 1.3.31 right now.
>
>
> Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SWIG versions - why not 1.3.31 yet?
Posted by Daniel Rall <dl...@collab.net>.
On Wed, 26 Sep 2007, Max Bowsher wrote:
> Max Bowsher wrote:
> > Does anyone know why our SWIG upper bound is still set at 1.3.29? Is
> > there any reason not to increase to 1.3.31?
> >
> > Meanwhile, should we be taking this opportunity to increase the lower
> > bound? I don't imagine anyone's making a habit of testing new binding
> > development across the entire range, and I seem to remember SWIG 1.3.24
> > -> .25 being a significant change.
>
> Additional thoughts - I just went and looked at the SWIG release history:
>
> 2006-11-20 1.3.31
> 2006-11-12 1.3.30 contained regression, next release 8 days later
> 2006-03-21 1.3.29
> 2006-02-11 1.3.28
> 2005-10-15 1.3.27
> 2005-10-09 1.3.26 contained regression, next release 6 days later
> 2005-06-11 1.3.25
> 2004-12-14 1.3.24
>
>
> Based on the above:
>
> (1) Since 1.3.31 was released 10 months ago, it would be unreasonable
> not to support it if it is feasible to do so.
>
> (2) Given that SWIG is not required to build the bindings from a
> release, only to do development on them, or to be a release manager, I
> see no reason to support versions more than one year old, if even that
> much. If we adopted that policy, we would drop support for all versions
> prior to 1.3.29 immediately, and in two months time, drop support for
> all versions prior to 1.3.31. Or, we could just go ahead and drop
> support for all versions prior to 1.3.31 right now.
I'm in favor of dropping support for the older versions of SWIG for
Subversion 1.5. I'd like to draw the line at 1.3.28 or 1.3.29.
Re: SWIG versions - why not 1.3.31 yet?
Posted by Joe Swatosh <jo...@gmail.com>.
On 9/29/07, D.J. Heap <dj...@gmail.com> wrote:
> On 9/29/07, Joe Swatosh <jo...@gmail.com> wrote:
> [snip]
>
> Yes, I do plan building the Ruby bindings -- I'd like to use 1.3.31 if
> all the issues get worked out. Otherwise, I'll have to use 1.3.24 as
> I have for the 1.4.x binaries -- anything later seems to cause the
> 'long long' problem as you've noticed.
Excellent. I'll switch to using 1.3.31 and make try to make sure that
1.3.24 keeps working. Thanks. I hope experts start checking out the
Perl and Python bindings.
--
Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SWIG versions - why not 1.3.31 yet?
Posted by "D.J. Heap" <dj...@gmail.com>.
On 9/29/07, Joe Swatosh <jo...@gmail.com> wrote:
[snip]
> I can't build the Perl bindings with VC6 + SWIG 1.3.25 (same long long
> issue, I believe). I reported that and that the Python bindings have
> been causing an access violation on list a few weeks ago.
>
> Assuming that you will be building the WIN32 binaries when 1.5 is
> released, what version of SWIG will you be using? I'm trying to keep
> the Ruby bindings building and passing tests, and when the time comes,
> I'm hoping you'll build them, too. If that's the case I want it to be
> as painless for you as possible, so I'd switch SWIG versions to match
> your plans.
Yes, I do plan building the Ruby bindings -- I'd like to use 1.3.31 if
all the issues get worked out. Otherwise, I'll have to use 1.3.24 as
I have for the 1.4.x binaries -- anything later seems to cause the
'long long' problem as you've noticed.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SWIG versions - why not 1.3.31 yet?
Posted by Joe Swatosh <jo...@gmail.com>.
Hi D.J.
On 9/29/07, D.J. Heap <dj...@gmail.com> wrote:
> On 9/26/07, David James <ja...@cs.toronto.edu> wrote:
> [snip]
> >
> > Does Subversion build on Windows with VC6 and VS.NET using SWIG
> > 1.3.31? I vaguely recall that some Microsoft compiler choked on the
> > output of newer versions of SWIG.
>
>
> The perl bindings will not currently build with VC6 + SWIG 1.3.31 --
> it doesn't like 'long long' as I recall.
>
> However, the python bindings work fine, and I believe I've built the
> ruby bindings with it before (I don't have ruby setup at the moment).
> I think the same fix that was made for the python and ruby bindings
> just need to be made for perl, but I'm not positive since I know very
> little of swig.
>
> DJ
>
I can't build the Perl bindings with VC6 + SWIG 1.3.25 (same long long
issue, I believe). I reported that and that the Python bindings have
been causing an access violation on list a few weeks ago.
Assuming that you will be building the WIN32 binaries when 1.5 is
released, what version of SWIG will you be using? I'm trying to keep
the Ruby bindings building and passing tests, and when the time comes,
I'm hoping you'll build them, too. If that's the case I want it to be
as painless for you as possible, so I'd switch SWIG versions to match
your plans.
--
Joe
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SWIG versions - why not 1.3.31 yet?
Posted by "D.J. Heap" <dj...@gmail.com>.
On 9/26/07, David James <ja...@cs.toronto.edu> wrote:
[snip]
>
> Does Subversion build on Windows with VC6 and VS.NET using SWIG
> 1.3.31? I vaguely recall that some Microsoft compiler choked on the
> output of newer versions of SWIG.
The perl bindings will not currently build with VC6 + SWIG 1.3.31 --
it doesn't like 'long long' as I recall.
However, the python bindings work fine, and I believe I've built the
ruby bindings with it before (I don't have ruby setup at the moment).
I think the same fix that was made for the python and ruby bindings
just need to be made for perl, but I'm not positive since I know very
little of swig.
DJ
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SWIG versions - why not 1.3.31 yet?
Posted by Peter Samuelson <pe...@p12n.org>.
[David James]
> I do know that there are users who run './autogen.py && make
> extraclean-swig' so that they can rebuild the bindings with their
> personal version of SWIG, although I'm not sure why they do that.
Just to answer this last question: I do this, for the official Debian
Subversion packages, mainly to be sure I can. We advertise that all
our software is free, and we give you source code to everything ... but
what if you wanted to modify the swig bindings and then you found out
that they required some exotic version of swig that, for whatever
reason, isn't in Debian? Access to source (including the swig
bindings) is fairly useless without the ability to modify and rebuild
it, so philosophically, I think we've effectively promised our users
both things. By rebuilding everything from scratch _every_ time, we
can be confident that we're fully self-hosting (our whole OS is
buildable with the tools and libraries we ship.)
(Also, if we had to quickly issue something like a security update that
touched the bindings, that would be an unfortunate time to discover
that we needed to hack around a buggy and unsupported version of swig,
or autoconf, or whatever.)
--
Peter Samuelson | org-tld!p12n!peter | http://p12n.org/
Re: SWIG versions - why not 1.3.31 yet?
Posted by David James <ja...@cs.toronto.edu>.
On 9/26/07, Max Bowsher <ma...@ukf.net> wrote:
> Erik Huelsmann wrote:
> >> (2) Given that SWIG is not required to build the bindings from a
> >> release, only to do development on them, or to be a release manager, I
> >> see no reason to support versions more than one year old, if even that
> >> much. If we adopted that policy, we would drop support for all versions
> >> prior to 1.3.29 immediately, and in two months time, drop support for
> >> all versions prior to 1.3.31. Or, we could just go ahead and drop
> >> support for all versions prior to 1.3.31 right now.
> >
> > If we drop it in 2 months, given the low number of people impacted,
> > why not drop it right now?
>
> Well, yeah, that's what I was implying in my last sentence above.
Does Subversion build on Windows with VC6 and VS.NET using SWIG
1.3.31? I vaguely recall that some Microsoft compiler choked on the
output of newer versions of SWIG.
Assuming that Subversion builds on all platforms with a given version
of SWIG, I'm +0 on blessing a single version of SWIG as the 'best
version of SWIG' for a given release.
If we also drop support for versions of SWIG other than the officially
blessed one that's fine with me. Is it okay with everyone else,
though?
I do know that there are users who run './autogen.py && make
extraclean-swig' so that they can rebuild the bindings with their
personal version of SWIG, although I'm not sure why they do that.
Cheers,
Daivd
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SWIG versions - why not 1.3.31 yet?
Posted by Max Bowsher <ma...@ukf.net>.
Erik Huelsmann wrote:
> On 9/26/07, Max Bowsher <ma...@ukf.net> wrote:
>> Max Bowsher wrote:
>>> Does anyone know why our SWIG upper bound is still set at 1.3.29? Is
>>> there any reason not to increase to 1.3.31?
>>>
>>> Meanwhile, should we be taking this opportunity to increase the lower
>>> bound? I don't imagine anyone's making a habit of testing new binding
>>> development across the entire range, and I seem to remember SWIG 1.3.24
>>> -> .25 being a significant change.
>> Additional thoughts - I just went and looked at the SWIG release history:
>>
>> 2006-11-20 1.3.31
>> 2006-11-12 1.3.30 contained regression, next release 8 days later
>> 2006-03-21 1.3.29
>> 2006-02-11 1.3.28
>> 2005-10-15 1.3.27
>> 2005-10-09 1.3.26 contained regression, next release 6 days later
>> 2005-06-11 1.3.25
>> 2004-12-14 1.3.24
>>
>>
>> Based on the above:
>>
>> (1) Since 1.3.31 was released 10 months ago, it would be unreasonable
>> not to support it if it is feasible to do so.
>>
>> (2) Given that SWIG is not required to build the bindings from a
>> release, only to do development on them, or to be a release manager, I
>> see no reason to support versions more than one year old, if even that
>> much. If we adopted that policy, we would drop support for all versions
>> prior to 1.3.29 immediately, and in two months time, drop support for
>> all versions prior to 1.3.31. Or, we could just go ahead and drop
>> support for all versions prior to 1.3.31 right now.
>
> If we drop it in 2 months, given the low number of people impacted,
> why not drop it right now?
Well, yeah, that's what I was implying in my last sentence above.
Max.
Re: SWIG versions - why not 1.3.31 yet?
Posted by Erik Huelsmann <eh...@gmail.com>.
On 9/26/07, Max Bowsher <ma...@ukf.net> wrote:
> Max Bowsher wrote:
> > Does anyone know why our SWIG upper bound is still set at 1.3.29? Is
> > there any reason not to increase to 1.3.31?
> >
> > Meanwhile, should we be taking this opportunity to increase the lower
> > bound? I don't imagine anyone's making a habit of testing new binding
> > development across the entire range, and I seem to remember SWIG 1.3.24
> > -> .25 being a significant change.
>
> Additional thoughts - I just went and looked at the SWIG release history:
>
> 2006-11-20 1.3.31
> 2006-11-12 1.3.30 contained regression, next release 8 days later
> 2006-03-21 1.3.29
> 2006-02-11 1.3.28
> 2005-10-15 1.3.27
> 2005-10-09 1.3.26 contained regression, next release 6 days later
> 2005-06-11 1.3.25
> 2004-12-14 1.3.24
>
>
> Based on the above:
>
> (1) Since 1.3.31 was released 10 months ago, it would be unreasonable
> not to support it if it is feasible to do so.
>
> (2) Given that SWIG is not required to build the bindings from a
> release, only to do development on them, or to be a release manager, I
> see no reason to support versions more than one year old, if even that
> much. If we adopted that policy, we would drop support for all versions
> prior to 1.3.29 immediately, and in two months time, drop support for
> all versions prior to 1.3.31. Or, we could just go ahead and drop
> support for all versions prior to 1.3.31 right now.
If we drop it in 2 months, given the low number of people impacted,
why not drop it right now?
bye,
Erik.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: SWIG versions - why not 1.3.31 yet?
Posted by Max Bowsher <ma...@ukf.net>.
Max Bowsher wrote:
> Does anyone know why our SWIG upper bound is still set at 1.3.29? Is
> there any reason not to increase to 1.3.31?
>
> Meanwhile, should we be taking this opportunity to increase the lower
> bound? I don't imagine anyone's making a habit of testing new binding
> development across the entire range, and I seem to remember SWIG 1.3.24
> -> .25 being a significant change.
Additional thoughts - I just went and looked at the SWIG release history:
2006-11-20 1.3.31
2006-11-12 1.3.30 contained regression, next release 8 days later
2006-03-21 1.3.29
2006-02-11 1.3.28
2005-10-15 1.3.27
2005-10-09 1.3.26 contained regression, next release 6 days later
2005-06-11 1.3.25
2004-12-14 1.3.24
Based on the above:
(1) Since 1.3.31 was released 10 months ago, it would be unreasonable
not to support it if it is feasible to do so.
(2) Given that SWIG is not required to build the bindings from a
release, only to do development on them, or to be a release manager, I
see no reason to support versions more than one year old, if even that
much. If we adopted that policy, we would drop support for all versions
prior to 1.3.29 immediately, and in two months time, drop support for
all versions prior to 1.3.31. Or, we could just go ahead and drop
support for all versions prior to 1.3.31 right now.
Max.