On Mon, Aug 15, 2016 at 5:43 PM, leif <not.rea...@online.de> wrote: > Johan S. H. Rosenkilde wrote: >>> leif wrote: >>> Well, depends on /what/ you write there... >>> >>> At least mentioning the different notions of skew polynomial evaluation >>> (and that currently only one, and which, is implemented) shouldn't hurt. >>> >>> And you could clearly state what aspects of the interface are probably >>> subject to change, and also which aren't. >>> >>> (You both still have to agree on the latter though, but my impression is >>> this isn't really the point where your opinions completely diverge.) >> >> I agree with Travis that such a warning is not fundamentally different >> from using @experimental. Also, casual users will probably miss it; if >> behaviour then later changes without them seeing a deprecation, that's >> annoying. Deprecation warnings are for both library developers and for >> users. >> >> My point is that I don't know what might change in the near-future. >> Though I could assign vague probabilities, I'd rather just say "feel >> free to use this but be prepared for some changes". "some changes" would >> cover name changes, changes in order of arguments, and in less common >> cases, behavioural changes (e.g. possibly to __call__). But overall, a >> user can count on the module to keep on existing and broadly providing >> at least the same set of functionality. >> >> I have a hard time seeing when @experimental could *ever* be used, if it >> is not applicable in this scenario. And back when @experimental was >> suggested, it was broadly received as a good idea >> (https://groups.google.com/forum/#!topic/sage-devel/LXWs6KOw0Lk). >> >>> Travis Scrimshaw wrote: >>> As Johan stated, my viewpoint is because you are not promising a stable >>> API with the @experimental, anyone who wants to develop code based upon >>> @experimental code either are requiring you, who put in the @experimental.. >>> to also fix their code should the API change or have their code be silently >>> broken (say, for lack of a specific doctest). So by marking everything as >>> experimental, you're effectively saying you should not build upon this. >> >> If a Sage developer builds module B on an @experimental module A, it >> puts no further burden on a developer who wants to later modify A: s/he >> will in either case need to fix B. @experimental modules are often >> introduced, as is the case in #13215, by developers who wish to use it >> themselves. In this case, A and B are developed by the same people. >> After a short while, say a year, the @experimental warning can be >> removed. > > What Sage IMHO really lacks is a true development (vs. stable) branch, > along with different releases (for "developers" as opposed to "ordinary" > users), which is pretty untypical. > > Every "stable" release is just identical to some beta/rc in a totally > linear way, and even critical bugfixes are almost never backported to > the previous/current stable release. And any "stable" release will in > turn simply contain *everything* that has been merged to that point > (since we in fact only have a single branch). > > Usually you make releases from trunk, not picking everything. But it's > also uncommon that only a single person (the "release manager") has > commit rights even on the develop branch. > > The above situation is of course also related (or due) to "Every Sage > user is [also] a Sage developer", as well as "Release often, release early". > > But I think large parts of Sage are meanwhile that mature, that we may > rethink the development / release strategy. > > There are most probably many "ordinary" users that are less interested > in brand-new research code or "exotic" features, but rather expect > properly maintained stable releases, i.e., including *quick* *bugfix* > releases, and not having to wait weeks or months for the next stable > release (of course bringing lots of other stuff, including new bugs) > just to get a single important (often build-related) issue fixed. > > > To some extent also trac tickets reflect this, as 99% are "major > defects", no matter whether they introduce new features or whatever. > It's often hard to figure out whether something's really broken (and > probably worth a bugfix release), or whether "defect" simply refers to > missing/incomplete features or the bare fact that there's a new release > of this or that available (orthogonal to what an update brings). At the > same time, some of the so-called "ordinary" users really think trac was > [just] our bug tracker, and every ticket would correspond to a bug in > Sage... > > Also distantly related is abusing "Milestones" for versions, instead of > using trac's Version field for that, and using milestones for what they > are meant for (namely, specific goals). > > > Getting /slightly/ off-topic, ;-) > > my 2 cents,
+1 to all of the above. I've been meaning to bring this all up again, but right now I'm just trying to remain focused on one or two things lest I feel overwhelmed. -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
