incubator-allura-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dave Brondsema <d...@brondsema.net>
Subject Re: (merged) Make SCM tools optional
Date Tue, 13 Nov 2012 18:07:17 GMT
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 : dave@brondsema.net
http://www.brondsema.net : personal
http://www.splike.com : programming
              <><

Mime
View raw message