Each month I take a snapshot of SLIME from CVS and include it in Quicklisp. When development was slow, this rarely resulted in broken versions. Now that development has moved to git and picked up speed, I'm concerned about including a version of SLIME that might have some temporary brokenness.
Can you recommend a way to raise the odds that Quicklisp uses a very good version of SLIME?
Zach
On Fri, Feb 7, 2014 at 1:22 PM, Zach Beane xach@xach.com wrote:
Can you recommend a way to raise the odds that Quicklisp uses a very good version of SLIME?
Monthly releases with 1-week freezes à la SBCL could be a solution.
Luís Oliveira luismbo@gmail.com writes:
On Fri, Feb 7, 2014 at 1:22 PM, Zach Beane xach@xach.com wrote:
Can you recommend a way to raise the odds that Quicklisp uses a very good version of SLIME?
Monthly releases with 1-week freezes à la SBCL could be a solution.
I like that idea a lot.
Zach
On Fri, Feb 7, 2014 at 2:59 PM, Zach Beane xach@xach.com wrote:
Monthly releases with 1-week freezes à la SBCL could be a solution.
I like that idea a lot.
Well, let's give it a go. Let's freeze around Feb 22nd, and release around March 1st. I'll wear the release manager hat this month. Is that compatible with Quicklisp's schedule?
Luís Oliveira luismbo@gmail.com writes:
On Fri, Feb 7, 2014 at 2:59 PM, Zach Beane xach@xach.com wrote:
Monthly releases with 1-week freezes à la SBCL could be a solution.
I like that idea a lot.
Well, let's give it a go. Let's freeze around Feb 22nd, and release around March 1st. I'll wear the release manager hat this month. Is that compatible with Quicklisp's schedule?
That sounds good. Is the current state of SLIME suitable for releasing as an initial baseline version, or should I just use the last CVS slime snapshot for now?
Zach
On Fri, Feb 7, 2014 at 3:17 PM, Zach Beane xach@xach.com wrote:
That sounds good. Is the current state of SLIME suitable for releasing as an initial baseline version, or should I just use the last CVS slime snapshot for now?
*puts release manager hat on*
Use the CVS snapshot for now.
Cheers,
Can you recommend a way to raise the odds that Quicklisp uses a very good version of SLIME?
how about introducing a branch or a tag for this? either specifically called 'quicklisp' or 'stable', where stable merely means a promise of relative stability compared to the bleeding edge?
i see a problem though: is there a way with git to mark a revision so that the devs can move that mark around unconstrained, while clients can also just git pull without any further action when the mark has been moved (i.e. no need for 'git reset --hard some-old-rev' in case of branches, or 'git tag -d the-moved-tag' or 'git pull -t' in case of tags)?
(the git devs don't want you to move around tags: https://www.kernel.org/pub/software/scm/git/docs/git-tag.html#_on_re_tagging)
if the end solution will specifically be about quicklisp, then this may not be a problem *if* the qicklisp build always clones and never pulls (which i don't know).
-
Attila Lendvai -
Luís Oliveira -
Zach Beane