On Tue, Jun 26, 2012 at 3:40 PM, Ian Lynagh <ian@well...> wrote:
> Please attribute any blame to me, not Paolo; he's only doing what I
> asked him to :-)
No blame to attribute. I just want to see things changed. :)
> When following option 1, I think starting from the HEAD rather than the
> last release makes sense in general:
Maybe. It doesn't matter as I want (2).
> * Some of the recent changes may have been to make the library work with
> GHC HEAD, and will therefore be necessary to work with the 7.6 branch
This works already today. I periodically get patches to e.g. network
and containers to make it work with the current GHC HEAD. That seems
to work fine.
> * Some libraries will need to have version bumps, which means that other
> libraries will need to loosen their dependencies, which means another
> release will be needed anyway
GHC is no different that any other library here though. Library A is
released and thus library B needs to be updated and released. The
argument here is that the author of library A needs to make a release
of the author of library B's package.
> so I think it's a reasonable default. But if it doesn't apply for a
> particular library, then no problem, just let us know - that's why we're
> e-mailing you :-)
So at least don't make releases of containers (I think that's the only
library I maintain that's released by GHC nowadays.) Can I please have
this preference sticky in case I'm on vacation next time one of these
emails go out?
Aside: I don't believe this has happened yet but imagine the odd
feeling of a library author, whose library was recently added as a GHC
dependency, getting an email saying that if he/she doesn't reply GHC
will make a release of his/her library!
> That sounds like it would also work. I assume there's some way to pull
> to a tag.
git fetch (and thus pull) retrieves all branches and tags by default
(and thus all commits pointed to by them.)