19 Dec
2012
19 Dec
'12
2:44 a.m.
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.
19 Dec
19 Dec
1:05 p.m.
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(a)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
2:41 p.m.
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(a)gmail.com>om>:
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(a)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
2:58 p.m.
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(a)gmail.com>om>:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
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:
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 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(a)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
20 Dec
20 Dec
2:19 a.m.
19 dec 2012 kl. 20:41 skrev Victor Seva <linuxmaniac(a)torreviejawireless.org>rg>:
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
2:51 a.m.
Hi Olle,
2012/12/20 Olle E. Johansson <oej(a)edvina.net>et>:
19 dec 2012 kl. 20:41 skrev Victor Seva <linuxmaniac(a)torreviejawireless.org>rg>:
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.
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.
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
2:59 a.m.
20 dec 2012 kl. 08:51 skrev Victor Seva <linuxmaniac(a)torreviejawireless.org>rg>:
Hi Olle,
2012/12/20 Olle E. Johansson <oej(a)edvina.net>et>:
Now it's all clear then!
/O :-)
19 dec 2012 kl. 20:41 skrev Victor Seva <linuxmaniac(a)torreviejawireless.org>rg>:
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.
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.
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. 
2:59 a.m.
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
10:25 a.m.
On Dec 20, 2012, at 2:59 AM, Juha Heinanen <jh(a)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
10:32 a.m.
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(a)isc.upenn.edu> wrote:
On Dec 20, 2012, at 2:59 AM, Juha Heinanen <jh(a)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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
12:44 p.m.
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(a)isc.upenn.edu> wrote:
--
Daniel-Constantin Mierla - http://www.asipto.com
http://twitter.com/#!/miconda - http://www.linkedin.com/in/miconda
On Dec 20, 2012, at 2:59 AM, Juha Heinanen
<jh(a)tutpro.com> wrote:
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev 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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
12:54 p.m.
20 dec 2012 kl. 18:44 skrev Daniel-Constantin Mierla <miconda(a)gmail.com>om>:
(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
4209
days inactive
4210
days old
11 comments
5 participants
participants (5)
-
Andrew Mortensen -
Daniel-Constantin Mierla -
Juha Heinanen -
Olle E. Johansson -
Victor Seva