On what versions should Trac patches be based?

I see that alphas and release candidates come out a lot faster than "released" versions of Sage. Should development patches be based on these pre-releases or on the current release? Furthermore, if I spot a patch on Trac that is based on an older version of Sage, should I go ahead and re-base the patch?

Notably, I have not found a clear answer in the Developer's Guide.

UPDATE: When producing the next stable, are the patches which are based on pre-releases "back-rebased" to the current stable? If so, is this a reason at all to favor basing on the current stable, rather than on the latest pre-release?

3 answers

First, develop on whatever version of Sage you have. Don't waste time downloading or building if you have an idea!

But once you are at the point to think about committing it, then it is worth going to the sage-release Google group and finding the latest alpha or release candidate and making sure that your patch at least applies to that. It is not correct to say that each patch builds on the released version; each alpha is based on the released version, but there are still patches that need to be rebased on other patches. There is certainly no 'back-basing' as in the update to the question.

This is annoying, I agree, but is worth doing. Many (most?) patches won't conflict, but it's worth knowing ahead of time; at least for me, rebasing is a long and tedious business.

Once one gets developing a fair amount, one will know where to look for "usual suspect" tickets or authors. Doing occasional searches in (say) symbolics will give you a sense of whether any symbolics patches are about to be merged, so that if you are going to do something in symbolics, you can be ready to base off of patch X with your patch Y.

Well, I think that nowadays that might be the case. However, it would be worth pointing out that someone could definitely test everything except whether it applies to the latest alpha, and then try to recruit someone else to test just that. If the patchbot/alpha system made any sense, this would be easier, but currently with the "from scratch" alphas that makes things hard.

Anyway, the point is that people should not be *discouraged* from reviewing, but rather say "positive review except it's too hard for me (given internet or machine or whatever) to test whether it applies to the latest alpha".

I think the goal is to have patches based on the latest version possible, but not to make this a barrier to people working on patches. Here are some more expanded comments, based on my limited experience:

Personally, I would develop patches based on stable releases of Sage. Sometimes alphas or release candidates have some test failures that are known to the release manager and will have to be resolved before the final release; these could be potentially confusing as a developer if your patch is working on a related component, since it may be difficult to tell which failures are caused by known issues, and which are caused by bugs in your patch. But there may be good reasons in some circumstances to base your patch on a pre-release version (e.g. it fixes something relevant to your patch). In the end, I think this is up to the developer.

As for developing with older stable releases, patches have to apply to the latest stable release in order to be finally included in a new release. Sometimes patches simply apply without problems to later releases, and then nothing has to be done. But if they don't, these problems definitely have to be fixed. I think most patch authors would be happy to have you rebase their patches -- I certainly would!

However, for the purposes of actually solving the programming or mathematical problems relevant to the patch, one doesn't have to necessarily work with the latest release of Sage. Since rebasing is usually a straightforward task, the real value in a developer's work is in writing the initial patch. Get something that works correctly in some version of Sage, and then make sure it works with the latest stable release. Of course the greater the gap between the version you develop with and the latest version, the more difficult the rebasing will be, but working two or three point releases behind the latest probably isn't a big deal.

Update: As @kcrisman points out, having a patch apply successfully to the latest stable release is necessary---but not sufficient---for the patch to be included in Sage. The patch must also apply to the latest pre-release, and not conflict with other patches to be merged in the next (pre-)release. He is right (of course!) to point out that testing against the latest pre-release is the best way to be sure your patch is ready to be merged.

However, motivation to test on the latest pre-release should be tempered by the understanding that the review process will probably take longer than expected (several pre-releases, and maybe several stable releases), and (as far as I know) binaries for pre-release versions are only available for the machines at the University of Washington. A person without access to these would have to build each pre-release from source just to test the patch. This can be tedious and time consuming, depending on one's resources, so I wouldn't necessarily recommend it for everyone.

Thank you everyone for your answers! I wish I could favorite all of them. :-) Since I am just starting out and don't have any mega-refactoring ideas (yet), I don't feel that basing off of the latest pre-release is a bother at all. If spending a little more of my time saves 10 other peoples' time, I think it is a good trade off. :-)