On 6 Mrz., 11:44, Keshav Kini <keshav.k...@gmail.com> wrote: > "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 !
Yes, I can see your point, thanks for clarifying it! My bad, my mind was still set to the "old" mode that any patches simply have to be based against some (preferably the latest) *official* Sage release. (With the obvious exception of a series of patches with well defined and clearly stated dependencies --- but the "root" patches still would have to be against the latest official version of Sage.) The downside is, that if two (or more) patches collide (which may not easily (or shall not) be put in one and the same "series of patches", for whatever reason), only one can win --- and all the others have to be rebased on the "then next" official Sage version. A downside that is the more acceptable, the higher the Sage release frequency is --- simply because then, the probability of such collisions decreases. I had this "old scenario" in mind when I wrote my answer, but didn't say so expicitly, sorry! Cheers, Georg -- 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
