"Georg S. Weber" <georgswe...@googlemail.com> writes: > Hi Keshav, > > honestly, I don't believe that what you describe, are arguments > against the workflow as such --- but rather arguments against waiting > for too long before releasing a new official version. Sage 4.7.2 was > released in last November, Sage 4.8 in January, and now it is March > and Sage 5.0 might still need some care (especially because there are > explicit goals for it, like "OS X 10.7 compatibilty" and "90% doctest > coverage", none of which is reached yet to my knowledge). So there are > (at least) two months between consecutive Sage versions currently. (I > do not know of any plans for some intermediate Sage 4.8.1 release.) > > If there was one (or more) Sage release per month, say roughly "every > 100 tickets at the latest", then I believe all the problems you > mention in your first post were much smaller, maybe gone altogether.
I must disagree with you. The main problem I see here is the destruction of published history. When you publish a repository containing some commits, and specifically tell developers to base new commits (or actually patches, as is the situation right now) on top of those commits, you must not later on destroy those commits and pretend they don't exist. Published history is meant to be built upon, not destroyed. And that doesn't change, no matter how few these commits are, or how frequently the process happens. Perhaps the inconvenience to developers will decrease if we increase the speed of Sage releases, but some inconvenience remains and the so does the fact that we are breaking VCS best practices. -Keshav ---- Join us in #sagemath on irc.freenode.net ! -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
