On 11/8/12 1:21 PM, Peter Hartmann wrote: > I did a push today and here's a rationale for some changes I've made to former > default. > > There's now a lil function in version.py that returns version string. > Setuptools > allows for two kind of additional version data: so-called "pre-release tag" > and > "post-release tag". Pre-release tags are default and can work with automatic > "dev" suffix addition. However, setuptools then assumes a package counts as a > pre-release of future version. This may work for projects with established > release schedule, where it is known beforehand what major version number will > the next version get. Allura seem to rely on continuous release, > differentiated > only by git tags, so the scheme used by version() uses data from git describe > as > a setuptools post-release tag. I've also kept it compatible with maj,min > versioning scheme, in case it'll be used in the future.
I'm looking at https://sourceforge.net/p/forgehg/code/ci/214820d7f555c8ac2e99a469778928664306d3a2/tree/forgehg/version.py and it seems that this would require the package to be installed from git. What if ForgeHg were installed without using git? E.g. I think 'python setup.py install' would copy the files and not the git info. In SourceForge's deployment scheme, we always deploy packages via specific tarballs (created by 'python setup.py sdist' if needed) not live from git. While Allura currently doesn't get any version info, almost all the packages it depends on do. I think it would be useful to have ForgeHg and any other libraries have version numbers and not rely & depend on a git working dir. There are several libraries, like Ming, that we could use as a reference. There are rarely major version number changes to Ming, but we make many releases and just bump the date on. You can see them here: http://pypi.python.org/pypi/Ming I think something like that would be good for ForgeHg. Ming's setup.cfg which controls that is at https://sourceforge.net/p/merciless/code/ci/2c204153d7a6c4db43354c59b50977d8be674c59/tree/setup.cfg > > Tests seem to work out of former source tree. The only thing needed is some > adjustment of paths in test.ini. I came to a thought that this should be > explained, and ended up writing a full README adding this and a bunch of other > info. It may require some grammar fixes, as I'm not a native english writer. I > used reStructuredText, even though Allura uses Markdown, because PyPI expects > reST readmes. I may add reST support to Allura later, or if it's already > there - > some kind of heuristics. > Cool. Docs is something we are short on :) Allura should be able to render reST docs. It uses the "pypeline" to handle several types of plain text formatting. But it requires a file extension, no heuristics currently. > Finally, I've retained the history of changes from Allura repository - it may > be > useful, even if for future reference only. One side-effect of using git > filter-branch with --subdirectory-filter was that the output is ForgeHg/*, not > ForgeHg/ itself. I find it better option in a separate repository, so I've > left > it as is. Should work well within former source tree structure anyways. Nice. Keeping the history is great. So what else needs to be done? -- Dave Brondsema : [email protected] http://www.brondsema.net : personal http://www.splike.com : programming <><
