Re: FreeBSD Ports: bumping haproxy from v1.2.18 -> v1.4.x

On 26-2-2010 16:42, Ross West wrote:
>
> Opening up a bit of discussion:
>
> For those Freebsd port users out there, I'm looking to submit updates
> for the haproxy port to take it from it's current v1.2.18 to the new
> v1.4.x tree - Leapfrogging the v1.3.x tree (which is part of the
> haproxy-devel port).
>
> Note: I'm _not_ looking to change the haproxy-devel port, which is
> currently part of the v1.3.x tree (v1.3.22 as of writing), and I
> believe is the port that most (all?) people are actually using.
>
> Obviously sometime in the future haproxy-devel should be changed to
> reference the snapshot or rc/dev builds that might be unstable, but
> that's not what I'm touching.
>
> Couple of benefits that I see of doing it this way:
>
> - Current systems running haproxy-devel port are untouched.
>
> - Less problems than pushing haproxy-devel to v1.4, and haproxy to
> v1.3, causing issues with config migrations for ports and software.
>
> - This'll eventually bring haproxy[-devel] back into line with the
> ports mentality of the main port being considered the active/stable
> port, with any sub ports being "special cases".
>
> Main problems I see:
>
> - People running the current haproxy port (ie: v1.2.18) will have a
> big version bump to deal with.
>
>
> Any thoughts/complaints/etc?
>

I don't have a problem with your approach..

However, the way I think it should go in the ideal situation, is that the haproxy port should contain the latest and greatest stable release (1.4.x), and the haproxy-devel port should go to the latest experimental snapshot.. If you think keeping a 1.3.x tree alive is usefull (which I do), create a port haproxy13 for that..

Sure, you would bump the haproxy version up from 1.2 to 1.4, but people who upgrade their ports should know to be careful around version upgrades..

As an example: If you switch from Squid 2.x to Squid 3.x your squid won't start anymore if you have the acl 'ALL' defined in your config.. You get an error, you google it, and it turns out in 3.x, the acl is already in the system, and hence you cannot define it again in your config. I'm fine with that, as long as the errors are clear ;)

-- 


With kind regards,


Angelo Höngens
systems administrator

MCSE on Windows 2003
MCSE on Windows 2000
MS Small Business Specialist
------------------------------------------
NetMatch
tourism internet software solutions

Ringbaan Oost 2b
5013 CA Tilburg
+31 (0)13 5811088
+31 (0)13 5821239

A.Hongens#netmatch.nl
www.netmatch.nl
------------------------------------------