Revision history [back]

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.

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.