On 26 Feb 2010, at 10:04, Angelo Höngens wrote: > 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 ;)
I agree with Angelo's ideal situation. I would just fix the versioning issue rather than just bandage it now and still have to fix it later. Version 1.3 should move to haproxy13, haproxy should be 1.4, and haproxy-devel should probably be removed until there is a new snapshot/beta/rc worthy of a port. Make sure UPDATING is very clearly documented with what is happening. It may be a bit painful (people currently using haproxy will have a big jump, and haproxy-devel users will have to switch to haproxy13), but this will have to happen sooner or later anyway. As a port maintainer myself, I say let's just do it right!
