You can always move the tag... seems kind of important to be able to exactly recreate the source for any binary that is distributed. Another method that is often used is to name the binary with both the date AND the git HEAD hash. cheers, JR On Tue, May 2, 2017 at 11:17 PM, Martin Winter < mwinter@opensourcerouting.org> wrote:
On 2 May 2017, at 18:11, JR Rivers wrote:
Are you adding tags to the git tree that align the snap names with the
exact hash that makes the snap?
Not at this time. But I’m including a “version” command which gives detailed information on the specific release
Here is how it looks like right now: (all frr snap commands are prefixed with the snap name, so vtysh is frr.vtysh - this is part of the snap system)
“frr.vtysh” returns:
dut:~# frr.vtysh
Hello, this is FRRouting (version 3.0-dev-20170428). Copyright 1996-2005 Kunihiro Ishiguro, et al.
dut#
and there is a frr.version command which just does a cat over a version file (which I create at build time). The frr.version basically returns the output of “zebra —version”, followed by some CI build information: (The CI information is only done since version 3.0 - frr 2.0 only returned the “zebra —version”)
dut:~# frr.version zebra version 3.0-dev-20170428 Copyright 1996-2005 Kunihiro Ishiguro, et al. configured with: '--prefix=' '--enable-vtysh' '--enable-isisd' '--enable-watchfrr' '--enable-ospfclient=yes' '--enable-ospfapi=yes' '--enable-multipath=64' '--enable-rtadv' '--enable-irdp' '--enable-user=root' '--enable-group=root' '--enable-pimd' '--enable-ldpd' '--enable-fpm' '--enable-protobuf' '--enable-configfile-mask=0640' '--enable-logfile-mask=0640' '--localstatedir=/var/run' '--sbindir=/sbin' '--bindir=/bin' '--sysconfdir=/etc/frr' '--with-pkg-extra-version=-dev-20170428' 'LDFLAGS= -L/build/frr/parts/frr/install/lib -L/build/frr/parts/frr/install/usr/lib -L/build/frr/parts/frr/install/lib/x86_64-linux-gnu -L/build/frr/parts/frr/install/usr/lib/x86_64-linux-gnu'
# Version Information for this version as built by NetDEF CI system # ------------------------------------------------------------ ----- # Source_GIT_URL='GitHub (https://github.com/FRRouting/frr.git)' Source_GIT_Commit=fc25a6680d63b78f9c35d6f97908a74734f04df7 Source_GIT_Branch='stable/3.0' Source_GIT_Describ=frr-2.0-1598-gfc25a668 Source_GIT_CommitTime_UTC='20170428.195610' Source_DejaGNU_tests_SHA='4a7014db71d6efdfa1e4b75da230a1dbc5 1cb842' CI_Build_Result_URL=https://ci1.netdef.org/browse/FRR-FRR30SNAP-2 CI_Build_TimeStamp='2017-04-29T04:38:31.979-07:00' CI_Build_TimeStamp_UTC='20170429.113831' Snap_Version='frr-3.0-dev-20170428' Snap_Deploy_TimeStamp_UTC='20170502.073019'
Happy to add some tag to the git if the community wishes - but please keep in mind that I plan to update on a regular interval (i.e. weekly for 3.0 and probably soon with every git change for development versions)
- Martin
On Tue, May 2, 2017 at 2:35 PM, Martin Winter <
mwinter@opensourcerouting.org
wrote:
I’ve started to upload 3.0-dev images to the snap store.
There are 4 channels on the snap store for different versions of the code: - stable - release candidate - beta - edge
The default channel which is used (unless the user overrides it), is the stable channel. “stable” and “release candidate” contain the 2.0 version of FRR and “beta” and “edge” now contain the 3.0 code
Snap’s are published for amd64, i386, armhf, arm64 and ppc64el CPU architectures.
For release versions, I’ve named them 3.0-dev-20170428 (date of the git when it was pulled) I’m planning to update the 3.0 code on the store on a weekly base.
I’m also thinking about pushing builds based on master to the edge channel (and keep 3.0 only on beta and soon release candidate channel).
I’ve attached some stat output from the snap store to this email as well.
- Martin
_______________________________________________ dev mailing list dev@lists.frrouting.org https://lists.frrouting.org/listinfo/dev