[MLton] MLton library project licensing

Matthew Fluet fluet at cs.cornell.edu
Sun Oct 8 12:50:52 PDT 2006


> Quoting Stephen Weeks <sweeks at sweeks.com>:
> [...]
>> Great.  We never did settle on a place.  I think that it would be best
>> to create a new toplevel project in the repository, parallel to the
>> mlton project.  I proposed
>>
>>   svn://mlton.org/mltonlib
>>
>> Since there were no objections, I've gone ahead and created it, with
>> the standard {branches,tags,trunk} subdirectories.
>
> I have no objections regarding the place, but I think that the standard
> repository layout is not ideal for a collection of libraries.  (Thanks
> to SVN this shouldn't matter as we can reorganize the repository.)  Below
> are some thoughts on flexible library development.

I think the "transparent per library branching" has a lot of good 
arguments for it.  However, I don't think any of them negate the utility 
of having "per repository branching".  Certainly, if mltonlib is being 
developed in parallel with mlton, but being distributed with the standard 
mlton packages, then it makes a lot of sense to branch and tag the 
mltonlib repository at the times when snapshots are taken for distribution 
with mlton.  Tags are useful for reconstructing the distribution after the 
fact.  I think branches are useful as well, for preparing a snapshot of 
the mltonlib repository for distribution.  Since "per library branching" 
is going on during development cycles, there should be a "per repository 
branch" to do nothing more than prepare the whole mltonlib for 
distribution: this includes deleting per library unstable branches, 
ensuring that no stable library revision depends upon unstable library 
revisions, etc.



More information about the MLton mailing list