On 19/02/2019 02:20, Chris Johns wrote:
On 19/2/19 12:55 am, Sebastian Huber wrote:
[...]
This also rolls into the issue of releases and I feel the the user manual should
focus on the tar files for releases and git access as a means of accessing
releases should be moved to an advanced topic. I am happy to leave what is in
the patch about this until we have our house in order and a release candidate
has been created. It is only tar balls that have a proper RTEMS version string,
git builds from the release branch or a tag will not. I will step hard on anyone
deploying and creating a release where the version string matches an existing or
future RTEMS version string.
Even with frequent releases, I would recommend to clone the Git repositories.
There are different views and some orgs and users will prefer a tarball that is
a specific version. There is a simplified trust framework that results from
using a release.
I
thought that a release is just a certain Git commit (the only one with the
release version) with a bootstrap packed as an archive?
A release is more, it is a complete collection of pieces we say will work
together. Yes, the rtems-<ver>.tar.xz is as you state, plus it has a change to
set the version string
(https://git.rtems.org/rtems-release/tree/rtems-release-kernel#n85). A release
also contains ready to use documentation as HTML and PDF, doxygen, examples,
packages, and every piece of source. A build of a release fetches all source
from RTEMS's servers which means the release is not effected by changes
referenced projects make in their sites over time.
A release as provided on our ftp host server is complete. A download of that
directory of files should be all you need. A user does not need to learn all the
relationships and details across all our parts, packages, configuration etc to
use RTEMS. They can trust the release as a black box packages without needing to
look inside at how it was arrived at.
I am not discounting the value a git based process can have, however across all
of RTEMS's life formal releases are tarballs and we should document and promote
this before alternatives. I feel any change to this policy should be discussed
away from a documentation change. We need to reflect what we have and that is
all I am saying here. :)
Ok, I think we should add this content somewhere to the user manual as
background information Git clones vs. release archives.
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
