Hi,
can, please, someone create the tag for the v3.3.3 so It would be easier to track patches between releases.
Thanks in advance and keep the good work.
Hello,
I have nothing against if there is any developer that want to undertake this task, eventually some more that could make the releases better.
Cheers, Daniel
On 12/19/12 8:44 AM, Victor Seva wrote:
Hi,
can, please, someone create the tag for the v3.3.3 so It would be easier to track patches between releases.
Thanks in advance and keep the good work.
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
I really don't see any task apart of doing a "git tag v3.3.3" "git push origin v3.3.3" in the moment of the realease.
Am I missing something? Do you want me to do such work?
2012/12/19 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
I have nothing against if there is any developer that want to undertake this task, eventually some more that could make the releases better.
Cheers, Daniel
On 12/19/12 8:44 AM, Victor Seva wrote:
Hi,
can, please, someone create the tag for the v3.3.3 so It would be easier to track patches between releases.
Thanks in advance and keep the good work.
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
There are couple of tag types to decide which one to use and then I thought that past releases should be tagged as well if the tags are important to community. Practically is about spotting the commit to Makefile.defs that sets the version -- the commit message should present that very clear.
Cheers, Daniel
On 12/19/12 8:41 PM, Victor Seva wrote:
I really don't see any task apart of doing a "git tag v3.3.3" "git push origin v3.3.3" in the moment of the realease.
Am I missing something? Do you want me to do such work?
2012/12/19 Daniel-Constantin Mierla miconda@gmail.com:
Hello,
I have nothing against if there is any developer that want to undertake this task, eventually some more that could make the releases better.
Cheers, Daniel
On 12/19/12 8:44 AM, Victor Seva wrote:
Hi,
can, please, someone create the tag for the v3.3.3 so It would be easier to track patches between releases.
Thanks in advance and keep the good work.
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla - http://www.asipto.com http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
19 dec 2012 kl. 20:41 skrev Victor Seva linuxmaniac@torreviejawireless.org:
I really don't see any task apart of doing a "git tag v3.3.3" "git push origin v3.3.3" in the moment of the realease.
Am I missing something? Do you want me to do such work?
At least one of the people asking for this stated as a reason "to be able to follow bug fixes".
We do bug fixes in the 3.3 branch in git - unless we change policy, create a 3.3.3 branch and start cherry picking between them all.
So far a release never changes - a 3.3.3 tag will never change, it's the same as the .tar.gz, it is frozen. If you want to get bug fixes for 3.3.3, then check out the 3.3 branch from git and follow that.
This doesn't mean that tagging is useless, it serves a purpose but not the one asked for.
/O
Hi Olle,
2012/12/20 Olle E. Johansson oej@edvina.net:
19 dec 2012 kl. 20:41 skrev Victor Seva linuxmaniac@torreviejawireless.org:
I really don't see any task apart of doing a "git tag v3.3.3" "git push origin v3.3.3" in the moment of the realease.
Am I missing something? Do you want me to do such work?
At least one of the people asking for this stated as a reason "to be able to follow bug fixes".
We do bug fixes in the 3.3 branch in git - unless we change policy, create a 3.3.3 branch and start cherry picking between them all.
But the issue is just that. It's easier to know the precise commit of the release, the asked tag v3.3.3. That's what I'm talking about.
So far a release never changes - a 3.3.3 tag will never change, it's the same as the .tar.gz, it is frozen. If you want to get bug fixes for 3.3.3, then check out the 3.3 branch from git and follow that.
If I want now to know how many changes are from the release I have to check all the logs and guess.
This doesn't mean that tagging is useless, it serves a purpose but not the one asked for.
Maybe I was not clear enough.
Greatings, Víctor
20 dec 2012 kl. 08:51 skrev Victor Seva linuxmaniac@torreviejawireless.org:
Hi Olle,
2012/12/20 Olle E. Johansson oej@edvina.net:
19 dec 2012 kl. 20:41 skrev Victor Seva linuxmaniac@torreviejawireless.org:
I really don't see any task apart of doing a "git tag v3.3.3" "git push origin v3.3.3" in the moment of the realease.
Am I missing something? Do you want me to do such work?
At least one of the people asking for this stated as a reason "to be able to follow bug fixes".
We do bug fixes in the 3.3 branch in git - unless we change policy, create a 3.3.3 branch and start cherry picking between them all.
But the issue is just that. It's easier to know the precise commit of the release, the asked tag v3.3.3. That's what I'm talking about.
So far a release never changes - a 3.3.3 tag will never change, it's the same as the .tar.gz, it is frozen. If you want to get bug fixes for 3.3.3, then check out the 3.3 branch from git and follow that.
If I want now to know how many changes are from the release I have to check all the logs and guess.
This doesn't mean that tagging is useless, it serves a purpose but not the one asked for.
Maybe I was not clear enough.
Now it's all clear then!
/O :-)
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.
-- juha
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
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
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
20 dec 2012 kl. 18:44 skrev Daniel-Constantin Mierla miconda@gmail.com:
(e.g., news on some sites like voip-info.org, release publishing on freecode.com, etc.)
I can add that to my list of news updates.
/O
-
Andrew Mortensen -
Daniel-Constantin Mierla -
Juha Heinanen -
Olle E. Johansson -
Victor Seva