> > 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. > > You're forgetting one important aspect: doctests. We require all doctests pass before something gets into Sage, so if A and B both get included, then A changes, it is up to the author of the changes to A to fix B. At least a deprecation doesn't force a change in B by the author of (changes to) A. Yet, if we just keep A waiting for a bit longer (and new, mostly independent, modules bitrot far, far slower than those based upon existing), we can alleviate this problem. I think it is also a fallacy to assume A and B are developed by the same people (I believe I am not you :P).
If we feel that the entire module should get marked as @experiemtnal, we might as well start adding in all code that might change as soon as it has 100% coverage, and mark it as @experimental. Being (slightly) ridiculous and taking things to the extreme, that logic somewhat leads to us marking all of Sage as @experimental. Being more serious, this actually is essentially Leif's suggestion, which I guess really boils down to teaching people how to pull things from trac and keeping an up-to-date beta version of Sage. Best, Travis -- 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.
