[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