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
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,
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
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
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
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
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
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
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
11 matches
Mail list logo
