[jitsi-dev] Github tags & releases


#1

Hello,

During the last community call, I've briefly mentioned this, but I wanted
to point out an approach that might be very simple. Hence the reiteration.

In Github, I find it hard to find the code state / commit that is an
official release of a Jitsi project. The continuous integration creates
tags and releases for every successful build. This muddies the water
considerably.

A pragmatic approach could be to _not_ have CI create a Github "release"
(but only use "tags" for CI). If you'd only use Github releases for
something that you consider to be a stable release, it becomes super easy
to identify what code belongs to what release.

This in turn allows me to easily base my downstream projects on your stable
code, instead of a random tagname (which is what I've been doing so far).
What do you think?

Regards,

  Guus


#2

Well,
Isn't the releases automatically created from tags, I'm not sure how
that works.
The only thing we do in ci is:
git tag -a "jitsi-meet_$BUILD_NUMBER" -m "Tagged automatically by Jenkins"
git push origin "jitsi-meet_$BUILD_NUMBER"

Regards
damencho

···

On Thu, Nov 2, 2017 at 3:57 PM, Guus der Kinderen <guus.der.kinderen@gmail.com> wrote:

Hello,

During the last community call, I've briefly mentioned this, but I wanted to
point out an approach that might be very simple. Hence the reiteration.

In Github, I find it hard to find the code state / commit that is an
official release of a Jitsi project. The continuous integration creates tags
and releases for every successful build. This muddies the water
considerably.

A pragmatic approach could be to _not_ have CI create a Github "release"
(but only use "tags" for CI). If you'd only use Github releases for
something that you consider to be a stable release, it becomes super easy to
identify what code belongs to what release.

This in turn allows me to easily base my downstream projects on your stable
code, instead of a random tagname (which is what I've been doing so far).
What do you think?

Regards,

  Guus

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#3

The only way to make Github distinguish between Tags and Releases is to attach a changelog or binaries to a Tag and thus making it a Release.

Ingo

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

···

On 2 Nov 2017, at 22:03, Damian Minkov <damencho@jitsi.org> wrote:

Well,
Isn't the releases automatically created from tags, I'm not sure how
that works.
The only thing we do in ci is:
git tag -a "jitsi-meet_$BUILD_NUMBER" -m "Tagged automatically by Jenkins"
git push origin "jitsi-meet_$BUILD_NUMBER"

Regards
damencho

On Thu, Nov 2, 2017 at 3:57 PM, Guus der Kinderen > <guus.der.kinderen@gmail.com> wrote:

Hello,

During the last community call, I've briefly mentioned this, but I wanted to
point out an approach that might be very simple. Hence the reiteration.

In Github, I find it hard to find the code state / commit that is an
official release of a Jitsi project. The continuous integration creates tags
and releases for every successful build. This muddies the water
considerably.

A pragmatic approach could be to _not_ have CI create a Github "release"
(but only use "tags" for CI). If you'd only use Github releases for
something that you consider to be a stable release, it becomes super easy to
identify what code belongs to what release.

This in turn allows me to easily base my downstream projects on your stable
code, instead of a random tagname (which is what I've been doing so far).
What do you think?

Regards,

Guus

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#4

Hurgh, you're right. There doesn't appear to be a way to create a tag that
doesn't show up in the list of github releases.

···

On 3 November 2017 at 06:34, Ingo Bauersachs <ingo@jitsi.org> wrote:

The only way to make Github distinguish between Tags and Releases is to
attach a changelog or binaries to a Tag and thus making it a Release.

Ingo

Freundliche Grüsse,
Ingo Bauersachs

-- sent from my mobile

> On 2 Nov 2017, at 22:03, Damian Minkov <damencho@jitsi.org> wrote:
>
> Well,
> Isn't the releases automatically created from tags, I'm not sure how
> that works.
> The only thing we do in ci is:
> git tag -a "jitsi-meet_$BUILD_NUMBER" -m "Tagged automatically by
Jenkins"
> git push origin "jitsi-meet_$BUILD_NUMBER"
>
> Regards
> damencho
>
>
> On Thu, Nov 2, 2017 at 3:57 PM, Guus der Kinderen > > <guus.der.kinderen@gmail.com> wrote:
>> Hello,
>>
>> During the last community call, I've briefly mentioned this, but I
wanted to
>> point out an approach that might be very simple. Hence the reiteration.
>>
>> In Github, I find it hard to find the code state / commit that is an
>> official release of a Jitsi project. The continuous integration creates
tags
>> and releases for every successful build. This muddies the water
>> considerably.
>>
>> A pragmatic approach could be to _not_ have CI create a Github "release"
>> (but only use "tags" for CI). If you'd only use Github releases for
>> something that you consider to be a stable release, it becomes super
easy to
>> identify what code belongs to what release.
>>
>> This in turn allows me to easily base my downstream projects on your
stable
>> code, instead of a random tagname (which is what I've been doing so
far).
>> What do you think?
>>
>> Regards,
>>
>> Guus
>>
>>
>> _______________________________________________
>> dev mailing list
>> dev@jitsi.org
>> Unsubscribe instructions and other list options:
>> http://lists.jitsi.org/mailman/listinfo/dev
>
> _______________________________________________
> dev mailing list
> dev@jitsi.org
> Unsubscribe instructions and other list options:
> http://lists.jitsi.org/mailman/listinfo/dev

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev


#5

Hurgh, you're right. There doesn't appear to be a way to create a tag that doesn't show up in the list of github releases.

That's what I observe as well: just pushing a tag also results in a github release being created automatically. I didn't find any way to disable this (and I'm waiting on a reply from github).

Regards,
Boris

···

On 03/11/2017 02:56, Guus der Kinderen wrote:

On 3 November 2017 at 06:34, Ingo Bauersachs <ingo@jitsi.org > <mailto:ingo@jitsi.org>> wrote:

    The only way to make Github distinguish between Tags and Releases is
    to attach a changelog or binaries to a Tag and thus making it a Release.

    Ingo

    Freundliche Grüsse,
    Ingo Bauersachs

    -- sent from my mobile

     > On 2 Nov 2017, at 22:03, Damian Minkov <damencho@jitsi.org > <mailto:damencho@jitsi.org>> wrote:
     >
     > Well,
     > Isn't the releases automatically created from tags, I'm not sure how
     > that works.
     > The only thing we do in ci is:
     > git tag -a "jitsi-meet_$BUILD_NUMBER" -m "Tagged automatically by
    Jenkins"
     > git push origin "jitsi-meet_$BUILD_NUMBER"
     >
     > Regards
     > damencho
     >
     > On Thu, Nov 2, 2017 at 3:57 PM, Guus der Kinderen > > <guus.der.kinderen@gmail.com > <mailto:guus.der.kinderen@gmail.com>> wrote:
     >> Hello,
     >>
     >> During the last community call, I've briefly mentioned this, but
    I wanted to
     >> point out an approach that might be very simple. Hence the
    reiteration.
     >>
     >> In Github, I find it hard to find the code state / commit that is an
     >> official release of a Jitsi project. The continuous integration
    creates tags
     >> and releases for every successful build. This muddies the water
     >> considerably.
     >>
     >> A pragmatic approach could be to _not_ have CI create a Github
    "release"
     >> (but only use "tags" for CI). If you'd only use Github releases for
     >> something that you consider to be a stable release, it becomes
    super easy to
     >> identify what code belongs to what release.
     >>
     >> This in turn allows me to easily base my downstream projects on
    your stable
     >> code, instead of a random tagname (which is what I've been doing
    so far).
     >> What do you think?
     >>
     >> Regards,
     >>
     >> Guus
     >>
     >> _______________________________________________
     >> dev mailing list
     >> dev@jitsi.org <mailto:dev@jitsi.org>
     >> Unsubscribe instructions and other list options:
     >> http://lists.jitsi.org/mailman/listinfo/dev
    <http://lists.jitsi.org/mailman/listinfo/dev>
     >
     > _______________________________________________
     > dev mailing list
     > dev@jitsi.org <mailto:dev@jitsi.org>
     > Unsubscribe instructions and other list options:
     > http://lists.jitsi.org/mailman/listinfo/dev
    <http://lists.jitsi.org/mailman/listinfo/dev>

    _______________________________________________
    dev mailing list
    dev@jitsi.org <mailto:dev@jitsi.org>
    Unsubscribe instructions and other list options:
    http://lists.jitsi.org/mailman/listinfo/dev
    <http://lists.jitsi.org/mailman/listinfo/dev>

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev