wxWidgets vs. wxWidgets-devel: a proposal

[Ryan Schmidt]

On Sep 25, 2012, at 03:24, Wahlstedt Jyrki wrote:

> On 22.9.2012, at 10.32, Ryan Schmidt wrote:
> 
>> We could take the approach that we take in some other ports, when versions are so different that other ports will need to be able to choose among them: always use a suffix, and make the ports simultaneously installable by installing to different locations.
>> 
>> My understanding is that wxWidgets uses odd numbered releases for development series. So 2.9 is a development series that will eventually become a stable version. I don't know whether that stable version will be 2.10 or 3.0. But it would mean that any hypothetical port that contains wxWidgets version 2.9.x should be called either wxWidgets210 or wxWidgets30.
> 
> As can be seen on the site, there is the stable version, now 2.8.12, the development version, now 2.9.4, and the previous stable version, 2.6.4. There's one development version release still to be expected, 2.9.5, before its release as a stable version, which will then be 3.0 (it is assumed to be released quite soon after 2.9.5, of course this is relative).
>> 
>> So under this plan, we would rename wxWidgets to wxWidgets28, we would rename wxWidgets-devel to wxWidgets210 or wxWidgets30, and we'd update all ports' dependencies according to the needs of each individual port. The port names wxWidgets and wxWidgets-devel would be retired a year later.
>> 
> This is probably a good thing to do. I'm in favour of moving the current branchless port name to …28, and the current -devel port to …30. The correct and meaningful time to do that would be, when 3.0 is released in some form (the stable port could be moved earlier).

wxWidgets-devel can be renamed to wxWidgets30 at any time, even before 3.0 is released. We already have a precedent of publishing numbered ports for prerelease versions, including gcc48 and clang-3.2.


>> I have no particularly strong feelings about what the ports are named or how you want to do it. I've been ignoring wxWidgets for years since 2.8 does not work on current OS X. It will be good to get that solved, however we do it.
>> 
>> 
>> Note that we also have ports wxWidgets26 and wxWidgets-python. Perhaps they can be considered in this overhaul as well.
> 
> I guess wxWidgets26 can be dropped after the current stable is the previous stable. I remember someone having made the request in the past for this port, but I'd assume the package requiring 2.6 series is also updated.

The only port I find that depends on wxWidgets26 is py-wxpython26, and I don't find any ports depending on that. So I agree they can be deleted, at any time.

wxWidgets-python is more confusing. I'll just let the many unresolved tickets speak to that:

https://trac.macports.org/query?status=!closed&summary=~wxwidgets-python&or&status=!closed&summary=~wxpython