Another thing that's important to what I need from the package system...
I'd like to promote a model of software development based on a mix of many modules written from the start to be reusable. A system comprises modules both off-the-shelf third-party and developed in-house. The in-house modules are developed in such a way that you can often selectively open-source the non-strategic ones at negligible cost.
A reality affecting this is that, as organizations develop their systems, they will often coordinate non-backward-compatible changes among their modules. Keeping the barrier to maintaining the open-source releases of those modules low means that open-source releases will also be non-backward-compatible at times I'd like the packaging and versioning scheme to make the incentive/altruistic dynamic work for both producer and open-source consumer of a package.
PLaneT had a very simple 90%+ solution to package naming and versioning that I thought was palatable to both producers and open-source consumers. Names were stable, major version were incremented to say believed-non-backward-compatible, consumers could say their baseline compatible version ("1.3+") or live dangerously, a Racket installation could have multiple versions of a package, and done. (There were some layered things that would have been very useful to add to PLaneT, such as a system version manifest, but the simple version model generally satisfied its purpose, and I'd say the main adoption barrier of PLaneT was only that the tools should've automated more.)
I appreciate that the new package system does a lot more than PLaneT, and also has some new conveniences (e.g., arbitrary HTTP and `git` locations). I'm not criticizing it. I just haven't figured out how to get it to do what I liked about PLaneT.
I'd like to use the new package system to work even better than PLaneT for my purposes. Maybe someone already has a great approach supporting the development model I described. If so, I'd like to hear about the approach, so that hopefully I can adopt it the next time I have a free weekend. (I had intended to convert my PLaneT packages&tools&workflow to the new package system before the end of summer, but I haven't had what seemed like a sufficient block of free time to get it over with. Not knowing how I'm going to handle versioning in a satisfying way make me think I'd need more than a weekend.)
You might be thinking "well, people can just copy the various package code versions that they want into their SCM repositories, who needs versioning." That does happen, and that also is an easy way for code to get privately forked and improvements not shared back (or later dumped on github in unusable form), licenses lost as code is copied&pasted. New versions of the open source releases can also be hard for a consumer to adopt, when they get into copying and modifying. I'd like to encourage open source packages maintaining their identity, and have them work smoothly in the kind of reusability&modularity and open source sharing that we'd like to see, within the various incentive/altruism dynamics we have.
Neil V. -- You received this message because you are subscribed to the Google Groups "Racket Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/55E62AD0.4050007%40neilvandyke.org. For more options, visit https://groups.google.com/d/optout.
