Hello,
I can take care of preparing the release on git branch and deploy it to kamailio.org as so far.
However, maybe someone (more is even better) else volunteers to help with releases and do the extra work. Here is a list of tasks to be done: - create the tag per release (it will be the commit that sets the version in Makefile.defs) - take care of building rpm packages on opensuse build service (everything can be done via web) - take care of building backup debian packages on opensuse build service (again, everything can be done via web) - take care of notifying linux/unix distros that package kamailio about the new version - maybe some other things (e.g., news on some sites like voip-info.org, release publishing on freecode.com, etc.)
None of them is something complex, but still require time -- I did most of them in the past, with some delay from the moment of the release.
Any taker?
Cheers, Daniel
On 12/20/12 4:32 PM, Andrew Mortensen wrote:
I meant to include this link:
http://git-scm.com/book/en/Git-Basics-Tagging
There should be no problem retroactively tagging releases, though how valuable that would be in practice is another question.
andrew
On Dec 20, 2012, at 10:25 AM, Andrew Mortensen admorten@isc.upenn.edu wrote:
On Dec 20, 2012, at 2:59 AM, Juha Heinanen jh@tutpro.com wrote:
i don't mind tagging versions as long i don't need to cherry pick anything to them. it must be enough to cherry pick to x.y branches.
As far as most git operations are concerned, tags are just another reference to a point in the tree, like a commit identifier. Using tags won't change the current development model at all.
I'd like to suggest that if we begin using tags, which I strongly support, we also start GPG-signing those tags. Git does support lightweight tags, but they're purely pointers to specific commits in the tree history. They don't support signing, aren't checksummed, and won't have a tagging message (e.g., "Release 3.4.0").
Recent versions of git support signed commits, as well, which might also be valuable for the project, given the large number of people with commit access.
andrew _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev