On 11/20/2016 08:26 PM, David Lang wrote:
> replying to details other than the feeds concept/
> ...
>> There were two different definitions offered. I'm guessing that you meant
>> the
>> "build number" after the "major.minor" version number.
>
> not quite
>
> the branch would be Year.Month, ta
replying to details other than the feeds concept/
On Sun, 20 Nov 2016, James Feeney wrote:
Ok - thanks for taking the time to explain this versioning process. So now, I
should take the time to "feed it back" and see if I understand. Ha!
it does not require twenty different variables but it
On Sun, 20 Nov 2016, Jo-Philipp Wich wrote:
- git://git.lede-project.org/source.git
- feeds.conf.default: git://git.lede-project.org/feed/packages.git
- feeds.conf.default: git://git.lede-project.org/project/luci.git
- feeds.conf.default: git://git.lede-project.org/feed/routing.git
- feeds.
the 'feeds'.
LEDE maintains this structure and uses the same feeds as OpenWRT
David Lang
On Sun, 20 Nov 2016, James Feeney wrote:
Date: Sun, 20 Nov 2016 18:11:16 -0700
From: James Feeney
To: lede-dev@lists.infradead.org
Subject: Re: [LEDE-DEV] Release Preparation Questions
Ok - thanks fo
Ok - thanks for taking the time to explain this versioning process. So now, I
should take the time to "feed it back" and see if I understand. Ha!
> https://git.lede-project.org/source.git
404 Not Found
Hmm. Try Google...
https://git.lede-project.org/?p=source.git
description LEDE Source R
Hi,
> Right off, I see the term "buildno" being used twice in a "name": 1) "version
> number X.Y.Z ... Z the build number", and 2) "$version/targets/ar71xx/generic/
> packages/$buildno". This appears redundant, and redundancy is a bad idea in
> this context.
$version will contain just X.Y, there
Hmm - A few comments from a naive outsider -
> 1) Images shall have a version number X.Y.Z where X is the year of
> release, Y the month and Z the build number produced by buildbot
>
> 2) The nonshared base repository holding kmods will be copied for each
> consecutive build, so there will be
On 19.11.2016 19:42, Jo-Philipp Wich wrote:
> $version = the base version number, e.g. 16.11 - this is what I'd like to
be the main identifier
> $nickname = the symbolic name for a release branch, e.g. "Rolling Rabbit"
- due to its arbitrary nature I do not want it to be part of directories or
Some other consideration when thinking about tags:
Ideally we should rewrite the feeds.conf.default in the repository to
pin down the specific revisions used for the feeds which means that we
should likely produce automatic commits + automatic tags prior to
issuing the binary build.
This can happ
Hi David,
> does it really make sense to make a branch instead of just tagging
> commits? Is there really an expectation that there will be different
> changes in a release branch vs the mainline (especially for feeds, I can
> see an argument for the lede source in that you may backport some fixes
Hi Luiz,
> We need both: branch for the new release and tag the released commit
> and each subrelease (ex: x.y.2)
as mentioned in my other mail to Hannu we can automatically emit tags
for builds we publish but keep in mind that this will likely only work
for the base repository and not for the ex
Hi Hannu,
sorry that some things where confusing, the mail was written in a hurry.
> I would prefer to have clear branches like "lede-16.11" for all the
> repos. Tags will not be sufficient when updates are made to the packages
> after the release and people compile new builds.
I too think that
I like your release approach in general.
I would prefer to have clear branches like "lede-16.11" for all the repos.
Tags will not be sufficient when updates are made to the packages after the
release and people compile new builds. (case for branch arises when a package
has after a release firs
We need both: branch for the new release and tag the released commit
and each subrelease (ex: x.y.2)
---
Luiz Angelo Daros de Luca, Me.
luizl...@gmail.com
___
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org
On Sat, 19 Nov 2016, Jo-Philipp Wich wrote:
Hi all,
I am currently on working on automating the required steps to cut a
proper release - in order to make this process as standardized and
repeatable as possible, I intend to script any required steps to avoid
the need for manual setup tasks as mu
Hi all,
I am currently on working on automating the required steps to cut a
proper release - in order to make this process as standardized and
repeatable as possible, I intend to script any required steps to avoid
the need for manual setup tasks as much as possible.
Ideally I want to reach a poin
16 matches
Mail list logo
