[racket] Worried about the new package manager not storing each version of a package

On 28/08/13 18:21, Greg Hendershott wrote:
> To the extent this is relying on package providers to do the right
> thing -- relying somewhat on convention and best practices:
>
> I think now would be a great time for a blog post (and maybe a
> RacketCon presentation) stating the best practices.
>
> Including things that seem obvious to core Racket devs. And including
> things that Jay might understandably want to be _optional_, and it's
> great that the system is flexible enough to allow more than just
> what's strongly recommend, but it's OK to strongly recommend.
>
> So maybe (IIUC) the recommended practices would include:
>
> 1. Host on GitHub.com.
> 2. Use Semantic Versioning (although Matthew IIRC it would need to
> support versions like "2.0.0" and "0.0.1" that it currently rejects?).
> 3. Once you reach 1.0.0, you _must_ start using Git tags for each new
> version (before then maybe it's not required).
>
> If I don't have that quite right... well then I think that goes to my
> point that we need something clearer. :) Whatever the guidelines, just
> make it super clear and checklist-oriented. That way, someone with a
> useful package for domain X can know exactly what's best, and do it
> without needing to understand the domain and history of package
> management so deeply. That is one thing I think that Planet 1 got
> right, and would be great to preserve, even if via different means.
>
> The new pkg mgr is technically still in beta, but it's getting used
> much more recently. As a result I think this kind of best practices
> guidance feels like it's "suddenly" necessary in a way it maybe didn't
> seem even just a month or two ago? At least that's my impression.
>
> p.s. Maybe Lawrence you'd still prefer a system that forces packages
> to do the right thing, but, you'd at least be more comfortable where
> the right thing is crystal clear to package providers and you can see
> if they're doing it or not?

I completely agree Greg, some best practice recommendations
would be great and certainly mitigate some of the risks that I have
outlined.  If a package author has something to aim for when
creating, organizing, and maintaining their package, then anyone
can look at their work (especially if hosted on something like github)
and decide whether to use it based on its merits.  The beauty of
github in particular is that anyone can clone the repo and be able to
track changes as well as roll back changes as needed for their local
installations.

In your mention of semantic versioning (http://semver.org for anyone
not familiar), you say about versions < 1.0  I'm currently using version
v0.2.1 as the version of my xdgbasedir package without problems, so
I don't think its an issue, unless it comes up when specifying a dependency.

To your recommendations I would add:

     * A reminder of the importance of testing
     * How to manage a release, perhaps with different branches
     * For github users: how to tag a release

To get the ball rolling I have written a post to show how to render a 
package's
scribblings to gh-pages on github:
http://techtinkering.com/2013/08/29/rendering-racket-package-scribblings-on-github-using-gh-pages


Best wishes



Lorry

-- 
vLife Systems Ltd
Registered Office: The Meridian, 4 Copthall House, Station Square, Coventry, CV1 2FL
Registered in England and Wales No. 06477649
http://vlifesystems.com