In case it's useful, I'll share my impressions as a recent addition to this group.
I have some experience with rolling out software, gathered in a different field. Where I come from we release often (I think we've averaged in the 30+ cuts per year, roughly 2 every 3 weeks), and our users have tolerance for the occasional rollback, and they roll forward relatively happily. One very important difference is that in that environment it is built into the infrastructure a solid mechanism for picking the software version per project, so that you could be working on several different versions of the software in the same day or so that were transparently tracked for you to stay on their corresponding working files. It seems to me the people that I hear speaking (maybe with the exception of HanWen) have a low level of confidence in the ability of the regression/test suite to provide adequate coverage of the scenarios needed by your current users. (Otherwise I don't even know why this is a discussion in the first place) I would consider this your highest priority: trusting your tests is absolutely crucial. A release going out that passes tests and fails in the field should be brought to be a "0 probability" event. This won't ever be the case for real, hence the occasional rollback: when user X rolls back, a test is made and added to the suite so this won't happen again (preaching to the choir, I get it). I wouldn't give a second of thought to folks rolling back a binary as long as a) you're proactive in saying clearly that there's be a problem and here's how you fix it (roll back, and roll forward once you get the next binary, say); b) this happens rarely, obviously. The other aspect that I observe reading this exchange is that nobody is talking about Scheme source in client code. I see you discussing how to pick up the differences between Guile 1.8 and 2.2 in the shipped source, but I don't recall seeing a discussion focusing on user-side changes. And in fact, this is a similar point to the previous one: either these differences are there and are material or they are not. In the second case, you should go ahead and move to 2.2. In fact I'd think you ought to ship current-ish (read non 2.2-specific) scheme source (with bugfixes) with the new runtime, and let that soak in userland for a bit (say 2.24 is that, and then 2.26 contains 2.2 specific source). As I read some people saying certain distributions are already shipping binaries based on Guile 2.2, I suspect maybe 2.22 (on those distributions) is a passable proxy for this stage. In the first case (Guile 1.8 vs 2.2 actually makes a real difference in source semantics and correctness(*), forget about the speed) your first concern must be what to do about users migrating their source and what cost will that be, in terms of time investment, instabilities or defects introduced and all that, which will dominate your ability to reduce your maintenance exposure making sure the majority of your user base will in fact pick up the new release line. (*) not that this seems to me a very realistic thing for the Guile folks to do intentionally Last thought: as I am currently learning Scheme and Guile, and I noticed 3.0.x has been out for a couple years now and seems to be benchmarking with speeds comparable to the 1.8.x line (according to their release notes). Given the switch to 2.2 hasn't happened yet, and as I am reading through these emails, it has been a long process, wouldn't moving to 3.0 instead be a better way to capitalize on the effort and push out the next round of this level of pain to a later date? (Again, I am expecting this has been discussed before, but still occasionally it's good to re-evaluate decisions: circumstances change, new evidence comes up, time goes by) I do realize this will stir many folks, and that this subject is understandably very sensitive, but it's possible that a pause and refocusing could be of use. I feel a lot of drive and energy and dedication to the project from all of you, and it seems very clear to me the folks that are writing maintain very high ethical standard and truly want the best for the project. This is the reason why I joined lilypond-devel btw, the people are awesome. (and I'll admit I also think the program is pretty cool ;) ). However, I also think I observe you all having a difficult time trusting that things will go well, there seems to be a high level of fear that "something bad" will happen. If I may propose a perspective: don't have fear of that, because something will break for sure. Nobody can avoid that, but what you can do, and what will make a positive difference to your users is your ability to help them through the stumble, support them in their difficulties, and keep moving ahead together. Thanks for your time, hopefully some of these thoughts can be of use L
