> On May 12, 2016, at 3:51 AM, René J. V. Bertin <[email protected]> wrote: > > Ryan Schmidt wrote: > > >>> is released as a stable version it should be renamed to llvm-3.9. The >>> ports llvm-3.9 and llvm-3.9-devel are still drop-in replacements. >> >> This makes it much more difficult on developers when the time comes for a >> port >> to graduate from development to stable status, as I'm currently doing with >> gcc6. I don't want to impose that extra work on myself or other developers. > > Why? As you said yourself all that's needed is using a path:-style > dependency. > That's hardly extra work,
It is extra work for the maintainer to convert all the existing port: dependencies to path: dependencies. It is extra work for the maintainer to rename the port from -devel to non-devel when it goes stable, and to maintain for one year the -devel stub port marked as replaced_by the non-devel port to facilitates upgrades. It is extra work for the user to manually uninstall the -devel port after the port has been renamed to the non-devel version, since MacPorts currently does not do so automatically (https://trac.macports.org/ticket/27552). And all this extra work for no benefit. > and it's probably a good idea to leave that style in > place even after the release version of the dependency is produced. It's > probably not because llvm 3.8.1 goes stable that there will be no 3.8.1+i > that > could be tested as a -devel port first. I don't have any interest in continuing to offer development versions of a port that has gone stable, in the case where we offer multiple versions of that port. > The advantage of using a -devel (sub)port rather than (or in addition to) a > category is that other ports can actually depend on the -devel port, if > necessary. For instance, clang-3.8-devel (clang-devel-3.8?) would probably > have > to depend on llvm-3.8-devel (llvm-devel-3.8). No need for this, if there are no -devel ports for these, as there currently aren't. > Also, -devel subports can in many cases be subports of the main/release port > because they most likely share a lot of code. I do that all the time with my > KF5 > ports. _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
