Checkout a tagged release's source code (like v18.06.1)

@hnyman, does this still apply to the v17.01.0 head if you download the source as an archive?

I compiled a new build but I have the same issues, buildnumber is unknown and the base-files under software.
I will to re-compile using your command.

Loading final 17.01.0 as archive and building from it should work OK as @jow fixed the tagging by adding version & date files to the final tagged commit.

But I have not tested it myself, yet.

When downloading head 17.01 as an archive gives the same issue also with your command. With git all went fine.

The archive download and build only works for the release tags like 17.01.0.. downloading the head of 17.01 branch should be done with git.

@hnyman thank you for clearifying that.

The advice is valid for the 17.01.1 release:

$ git fetch --tags
remote: Counting objects: 42, done.
remote: Total 42 (delta 27), reused 27 (delta 27), pack-reused 15
Unpacking objects: 100% (42/42), done.
From https://github.com/lede-project/source
 * [new tag]               v17.01.0     -> v17.01.0
 * [new tag]               v17.01.0-rc1 -> v17.01.0-rc1
 * [new tag]               v17.01.0-rc2 -> v17.01.0-rc2
 * [new tag]               v17.01.1     -> v17.01.1

$ git checkout v17.01.1
Note: checking out 'v17.01.1'.

You are in 'detached HEAD' state. You can look around, make experimental
...
HEAD is now at 48461b5abc... LEDE v17.01.1: adjust config defaults

$ git log --oneline -n 4
48461b5abc LEDE v17.01.1: adjust config defaults
7eb58cf109 utils/f2fs-tools: Update to 1.8.0
1d76542cca busybox: add musl compatible nslookup replacement
6ca5ccc620 kernel: update kernel 4.4 to 4.4.61

Note:
Checking out the exact release locks also the feeds (packages, LuCI etc..) to the release moment. Later fixes made to LuCI and packages will not get compiled into the firmware. Similarly fixes made later to the 17.01 branch main sources do not get included.

For most users it is usually better to compile from the HEAD of the 17.01 branch instead of compiling the exact release like 17.01.1. When compiling from branch HEAD, the later fixes in the main 17.01 source and in the feeds get included into the build. To achieve that, do not checkout the release tag "v17.01.1" but checkout the branch "lede-17.01":
git checkout lede-17.01

which means that

git clone https://github.com/openwrt/openwrt.git
cd openwrt/
(git fetch --tags)
git checkout openwrt-18.06

is the same as

git clone -b openwrt-18.06 --single-branch https://git.openwrt.org/openwrt/openwrt.git

Right?

Checkout means checking out branches or tracking branches. This was confusing for me since the branch openwrt-18.06.1 is not "selectable" on the github web ui

And

git checkout openwrt-18.06

is not the same as

git checkout -b openwrt-18.06

Not quite. The files themselves are the same, but the git history is more limited:
The "clone single-branch" does not fetch the commit history for other branches like master, so it will be impossible to e.g. cherry-pick a later commit from master.

There is no branch 18.06.1
There is the 18.06 branch and the tag 18.06.1 pointing to the 18.06.1 commit in the 18.06 branch.
See the 18.06 branch changelog and notice the tag in the history: https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=4ffed014a36b3d3ed9d71227adb8158ac8fd7564

I see. The commits were tagged on the same dates
https://git.openwrt.org/?p=openwrt/openwrt.git;a=shortlog;h=4ffed014a36b3d3ed9d71227adb8158ac8fd7564
as the release history shows
https://openwrt.org/releases/18.06/start

History

How is the date defined when a commit is getting tagged with e.g. 18.06.1? Is there a voting of the major contributors or something like that?

How do I get the 18.06.1 of the openwrt branch?
Do I get it if I
git clone https://github.com/openwrt/openwrt.git
cd openwrt/
(git fetch --tags)
git checkout v18.06.1
?
Or
git clone -b openwrt-18.06
git checkout v18.06.1

Yes.
Just like the three examples above (about various 17.01 tags) show.

Below is example about v18.06.1 for you.
(just for fun, as there is no new information compared to the previous examples except the current tag).

perus@ub1804:/Openwrt$ cd /tmp

perus@ub1804:/tmp$ git clone https://github.com/openwrt/openwrt.git
Cloning into 'openwrt'...
remote: Counting objects: 437912, done.
remote: Compressing objects: 100% (88/88), done.
remote: Total 437912 (delta 36), reused 19 (delta 9), pack-reused 437815
Receiving objects: 100% (437912/437912), 151.66 MiB | 8.19 MiB/s, done.
Resolving deltas: 100% (296538/296538), done.

perus@ub1804:/tmp$ cd openwrt/

perus@ub1804:/tmp/openwrt$ git fetch --tags

perus@ub1804:/tmp/openwrt$ git tag -l
reboot
v17.01.0
v17.01.0-rc1
v17.01.0-rc2
v17.01.1
v17.01.2
v17.01.3
v17.01.4
v17.01.5
v17.01.6
v18.06.0
v18.06.0-rc1
v18.06.0-rc2
v18.06.1

perus@ub1804:/tmp/openwrt$ git checkout v18.06.1
Note: checking out 'v18.06.1'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b <new-branch-name>

HEAD is now at 70255e3d62 OpenWrt v18.06.1: adjust config defaults

perus@ub1804:/tmp/openwrt$ git log --oneline | head -n 3
70255e3d62 OpenWrt v18.06.1: adjust config defaults
5eb055306f rpcd: update to latest git HEAD
e11df1eac6 openssl: update to version 1.0.2p

Easy enough?

I am not very sure if we are on the same track. isn't it that your are constantly driving on the master branch?
My question - to be more precisely- was in regard to the openwrt-18.06 branch.

You do neither clone the openwrt-18.06 branch nor checkout this one.
My question was:
How do I get the version 18.06.1 of the openwrt-18.06 branch? If this is possible at all.
You mentioned:

frood@kalimero:~/Documents/git/openwrttest2$ git clone https://github.com/openwrt/openwrt.git
Cloning into 'openwrt'...
...
frood@kalimero:~/Documents/git/openwrttest2$ cd openwrt/
frood@kalimero:~/Documents/git/openwrttest2/openwrt$ git fetch --tags
...
frood@kalimero:~/Documents/git/openwrttest2/openwrt$ git tag -l
reboot
v17.01.0
v17.01.0-rc1
v17.01.0-rc2
v17.01.1
v17.01.2
v17.01.3
v17.01.4
v17.01.5
v17.01.6
v18.06.0
v18.06.0-rc1
v18.06.0-rc2
v18.06.1
frood@kalimero:~/Documents/git/openwrttest2/openwrt$ git show-branch 
[master] kernel: bump 4.14 to 4.14.70
frood@kalimero:~/Documents/git/openwrttest2/openwrt$ git checkout v18.06.1
Note: checking out 'v18.06.1'.
...
frood@kalimero:~/Documents/git/openwrttest2/openwrt$ git show-branch 
[master] kernel: bump 4.14 to 4.14.70

I there a difference if I do

git clone -b openwrt-18.06 --single-branch https://git.openwrt.org/openwrt/openwrt.git
Cloning into 'openwrt'...
...
frood@kalimero:~/Documents/git/openwrttest$ cd openwrt/
frood@kalimero:~/Documents/git/openwrttest/openwrt$ git fetch --tags
...
frood@kalimero:~/Documents/git/openwrttest/openwrt$ git tag -l
reboot
v17.01.0
v17.01.0-rc1
v17.01.0-rc2
v17.01.1
v17.01.2
v17.01.3
v17.01.4
v17.01.5
v17.01.6
v18.06.0
v18.06.0-rc1
v18.06.0-rc2
v18.06.1
frood@kalimero:~/Documents/git/openwrttest/openwrt$ git show-branch
[openwrt-18.06] uqmi: pass-through ipXtable to child interfaces
frood@kalimero:~/Documents/git/openwrttest2/openwrt$ git checkout v18.06.1
Note: checking out 'v18.06.1'.
frood@kalimero:~/Documents/git/openwrttest/openwrt$ git show-branch
[openwrt-18.06]

My understanding is that this is a build of the openwrt-18.06 branch
https://downloads.openwrt.org/releases/18.06.1/targets/

The structure of git is too complex for me to try to explain, but suffice to say you don't need to check out a particular branch to get the 18.06.1 tag. All you need to do is check out the master and select the tag using git checkout <tag>.

Which is good for me, since I want to build the latest greatest master version with ath79 support.
And I was just wondering what I could do wrong to checkout the "other" branch or what someone could do if someone wanted to build a specific version of the openwrt-18.06 branch - if this is possible at all.
Just theoretically and expandable. But still interesting since I do usually have less touch points with git.

ath79 does not exist in the openwrt-18.06 branch, nor any of the tagged 18.06.x releases - you can only use master for this (and most of the rather important developments happen long after 18.06 was branched off, so you really wouldn't want to use it in 18.06 anyways, even if it would exist).

yes... and expandable
i was just wondering, since in the download and release section there is " Current Stable Release - OpenWrt 18.06.1"
Is this all the master branch being compiled for download? Never the "openwrt-18.06" branch?

OpenWrt 18.06.1 is compiled off the openwrt-18.06 branch.

Current stable release is always compiled from the stable branch(es), currently 18.06 (and 17.01)
Current stable release is never compiled from master.

Openwrt follows this kind of branch strategy:

  • all development happens in master. It progresses on, but no releases are made of it.

  • before major releases, a release branch is branched off from master. This branch will get separate fix commits and releases are made of that. No new features (like ath79) are normally added to the release branches after the branching.
    In the picture below, you can see 17.01 branch and 18.06 branch with the releases made from them.

  • releases are made from individual commits in release branch. 18.06.0 would be the first balloon on that branch, 18.06.1 the next one etc. (intermediate commits between releases are omitted from picture)

So there can be no "18.06.1 of the openwrt (master) branch".

image

1 Like

I think you are being confused by using the wrong way to check which branch a tag belongs to. Try

git branch -a --contains v18.06.1

1 Like

Thank you very much! For developers using git it might be basic knowhow.
For me it explains a lot.

But it also means that I cannot pick (checkout) and build a "stable" specific version with ath79 support (for the archer C7 v2).