Hi Hans,
I recently wrote the following post on the Quicklisp mailing list:
http://permalink.gmane.org/gmane.lisp.quicklisp/69
and you can read Zach's reply here:
http://permalink.gmane.org/gmane.lisp.quicklisp/70
Here's the final paragraph of Zach's reply, for the sake of convenience:
"If the updated Ediware projects have important improvements, I would love to see new versioned releases published in some formal way. If that's not going to happen, I can look into pulling the projects from git [...]"
I suspect formal release tarballs for each and every project in edicl would be quite a lot of work for you (as it probably was for Edi) so how about maintaining production-ready master branches (as in git-flow[1]) to make things as easy as possible for Zach?
Seb
[1] http://nvie.com/posts/a-successful-git-branching-model/
Hi Sebastian,
Sorry for the delay. I will switch to git-flow in the future, but that will take a little while. I would like to make a release in the not so far future as git repository has a number of improvements an bug fixes, but I still have not found the time to make a basic file system to go with the release. Any volunteers?
Hans Am 04.09.2011 17:01 schrieb "Sebastian Tennant" sebyte@smolny.plus.com:
Hi Hans,
I recently wrote the following post on the Quicklisp mailing list:
http://permalink.gmane.org/gmane.lisp.quicklisp/69
and you can read Zach's reply here:
http://permalink.gmane.org/gmane.lisp.quicklisp/70
Here's the final paragraph of Zach's reply, for the sake of convenience:
"If the updated Ediware projects have important improvements, I would love
to
see new versioned releases published in some formal way. If that's not
going
to happen, I can look into pulling the projects from git [...]"
I suspect formal release tarballs for each and every project in edicl
would be
quite a lot of work for you (as it probably was for Edi) so how about maintaining production-ready master branches (as in git-flow[1]) to make
things
as easy as possible for Zach?
Seb
[1] http://nvie.com/posts/a-successful-git-branching-model/
-- Emacs' AlsaPlayer - Music Without Jolts Lightweight, full-featured and mindful of your idyllic happiness. http://home.gna.org/eap
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
Quoth Hans Hübner hans.huebner@gmail.com:
Sorry for the delay.
No problem.
I will switch to git-flow in the future,
Oh good. I haven't actually used it myself yet but it made a lot of sense to me when I first read about it, so I thought I'd suggest it here.
but that will take a little while.
No problem.
I would like to make a [hunchentoot] release in the not so far future as [the] git repository has a number of improvements and bug fixes, but I still have not found the time to make a basic file system to go with the release. Any volunteers?
I'd be happy to help, if I can.
Could you provide a little more detail about what you'd like the volunteer to actually do and if I think it's something I have the time and skills for, I'll I'll contact you off-list.
Incidentally, the library I'd actually like to see updated soonest is cl-who as the version in Quicklisp doesn't include support for HTML5.
Perhaps I could assist with 'releasing' an updated version of cl-who as a warm-up to assisting you with a hunchentoot release?
Sebastian
On Fri, Sep 9, 2011 at 7:49 PM, Sebastian Tennant sebyte@smolny.plus.com wrote:
Incidentally, the library I'd actually like to see updated soonest is cl-who as the version in Quicklisp doesn't include support for HTML5.
Perhaps I could assist with 'releasing' an updated version of cl-who as a warm-up to assisting you with a hunchentoot release?
It's been a while (maybe two years ago), so I'm not totally sure, but I /think/ the unreleased version of CL-WHO contains architectural changes of mine which so far haven't been sufficiently documented and/or tested. You might want to take a look at this before you make a release.
Just a recommendation. Of course, you can proceed as you like... :)
Cheers, Edi.
PS: cl-who-devel on Cc.