[LEDE-DEV] More OpenWrt -> LEDE renames

On 10/05/16 09:33, Hannu Nyman wrote:
> The contents of those files, the related config options and the sources
> for each items might maybe be rationalised at the same time.

Good idea.

I think most of this can be beautifully handled by using git tags and
"git describe". Basically the simple idea is to tag a release, so
releases will have a clean name such as "15.05.1". I'll use "15.05.1" as
an example. Changes after that release would be shown as
TAG-NrOfCommits-Hash, e.g. "15.05.1-14-ge1357c0" (14 commits after
15.05.1, you can uniquely identify the commit by hash ge1357c0).

Improvements, such as including branch names would be possible, too.
Also see my patch below.

> There are at least four different kind of builds:
> * trunk snapshots/builds: Trunk codename designation, no release number,
> source revision, opkg download from snapshot repo

Could as well be git describe based on last tag as e.g.
"15.05.1-1238-ge1357c0". Or if you care about the name, we can tag
master with (say) "DD", or "master" after branching, then you'd have
"DD-1234-hash"

> * branch builds before release: Branch codename designation, release
> branch number known but no release yet, source revision

Tag as "15.05.1-rc1", "15.05.1-rc2"...

> * branch release builds: Branch codename designation, official release
> number, source revision, opkg download from release repo

Once a rc becomes a release, tag with "15.05.1" and rebuild.

> * branch builds after a release: Branch codename designation, last
> release number known + changes after it, source revision, opkg download
> from last release repo

Would automatically happen as explained above, e.g. "15.05.1-14-ge1357c0"

Greetings,
bruno

Den 2016-05-10 kl. 11:52, skrev Bruno Randolf:
>> On 10/05/16 09:33, Hannu Nyman wrote:
>> * branch builds after a release: Branch codename designation, last
>> > release number known + changes after it, source revision, opkg download
>> > from last release repo
> Would automatically happen as explained above, e.g. "15.05.1-14-ge1357c0"
It would be wonderful for small tinkerers like me to have opkg download
from a similarily named snapshot directory as we (or at least I) tend to
use or build from trunk (because of something like a new device or
feature) and then 6 months later realize that I forgot tcpdump or
autossh (or rather something like a kmod i.e. depending on the exact
kernel, but I hope you get the picture) and of course that is not so
easy to get hold of then (if I synced or used the "official" trunk build).
Would of course have costs regarding disk space, so this is merely a
question.

On Tue, 10 May 2016, Bruno Randolf wrote:

> On 10/05/16 09:33, Hannu Nyman wrote:
>> The contents of those files, the related config options and the sources
>> for each items might maybe be rationalised at the same time.
>
> Good idea.
>
> I think most of this can be beautifully handled by using git tags and
> "git describe". Basically the simple idea is to tag a release, so
> releases will have a clean name such as "15.05.1". I'll use "15.05.1" as
> an example. Changes after that release would be shown as
> TAG-NrOfCommits-Hash, e.g. "15.05.1-14-ge1357c0" (14 commits after
> 15.05.1, you can uniquely identify the commit by hash ge1357c0).
>
> Improvements, such as including branch names would be possible, too.
> Also see my patch below.
>
>> There are at least four different kind of builds:
>> * trunk snapshots/builds: Trunk codename designation, no release number,
>> source revision, opkg download from snapshot repo
>
> Could as well be git describe based on last tag as e.g.
> "15.05.1-1238-ge1357c0". Or if you care about the name, we can tag
> master with (say) "DD", or "master" after branching, then you'd have
> "DD-1234-hash"
>
>> * branch builds before release: Branch codename designation, release
>> branch number known but no release yet, source revision
>
> Tag as "15.05.1-rc1", "15.05.1-rc2"...

These will sort after 15.05.1, which may matter if the version ever becomes part 
of a package name

change - to ~ and it will sort before the release

so 15.05.1~rc1 15.05.1~beta1 etc

also 15.05.1-14-ge1357c0 will sort after the rc, not before it.

David Lang

>> * branch release builds: Branch codename designation, official release
>> number, source revision, opkg download from release repo
>
> Once a rc becomes a release, tag with "15.05.1" and rebuild.
>
>> * branch builds after a release: Branch codename designation, last
>> release number known + changes after it, source revision, opkg download
>> from last release repo
>
> Would automatically happen as explained above, e.g. "15.05.1-14-ge1357c0"
>
> Greetings,
> bruno
>
>
> diff --git a/include/version.mk b/include/version.mk
> index 9348a24..8bc5319 100644
> --- a/include/version.mk
> +++ b/include/version.mk
> @@ -21,7 +21,7 @@ qstrip_escape=$(subst ','\'',$(call qstrip,$(1)))
> #'
>
> VERSION_NUMBER:=$(call qstrip_escape,$(CONFIG_VERSION_NUMBER))
> -VERSION_NUMBER:=$(if $(VERSION_NUMBER),$(VERSION_NUMBER),15.05)
> +VERSION_NUMBER:=$(if $(VERSION_NUMBER),$(VERSION_NUMBER),$(REVISION))
>
> VERSION_CODE:=$(call qstrip_escape,$(CONFIG_VERSION_NUMBER))
> VERSION_CODE:=$(if $(VERSION_CODE),$(VERSION_CODE),Chaos Calmer)
> diff --git a/scripts/getver.sh b/scripts/getver.sh
> index 4643ca6..fa542f1 100755
> --- a/scripts/getver.sh
> +++ b/scripts/getver.sh
> @@ -17,9 +17,7 @@ try_svn() {
> }
>
> try_git() {
> -	[ -e .git ] || return 1
> -	REV="$(git log | grep -m 1 git-svn-id | awk '{ gsub(/.*@/, "", $0);
> print $1 }')"
> -	REV="${REV:+r$REV}"
> +	REV="$(git describe --tags --dirty)"
> 	[ -n "$REV" ]
> }
>
>
>
> _______________________________________________
> Lede-dev mailing list
> Lede-dev@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/lede-dev
>