On 19.05.20 05:11, daniel.sangorrin@toshiba.co.jp wrote: > Hello Dinesh, Jan, all > > Dinesh raised an important issue on another thread. I created a new thread to discuss about it. > >> From: Dinesh Kumar > [...] >> I have a question, while planning this activity can we define some version for CIP Core itself? As currently we have >> CIP Kernel versions and versions for individual application packages. >> e.g. If we want to share CIP Kernel and CIP Core version for IEC assessment we lack CIP Core version. >> May be we can discuss it in upcoming CIP Core meeting. > > I agree that we need to version our releases. In Debian there are point versions, but I don't think we need to follow that. Maybe we can just use a number such as the date of the release (eg. 20200519 <-- yearmonthday). Or the more common pattern "2020.05". How often should we release? What would be the required quality criteria? > > Some questions regarding versioning: > * should we also store metadata associated with a release? > * a package list manifest for each release (dpkg -l)? > * the cip-core branch and commit > * the cip-kernel branch and commit > * md5sum of the image When using a meta layer for generating the image - like isar-cip-core -, almost everything is described that way already, except for... > * do we need repository management infrastructure? > * mirror part of the debian repository (only the packages that we need) > * create snapshots for each release including the source code packages > ...the binary packages. So the second piece would be a versioned repo for those. That can be snapshot.debian.org, like we do in [1][2], but that this not a very reliable source (took me hours recently to rebuild [1] from there, you want a better mirror). > Storing metadata should not be too difficult, just add some script code to gitlab-ci. > > Keeping snapshots would require much more work and resources. I think this is not necessary since we are not going to rebuild images, and if we wanted we could do it somehow from the package list manifest and the upstream Debian ftp servers. The repo is required if we want to be serious regarding releases. Jan [1] https://github.com/siemens/meta-iot2050 [2] https://github.com/siemens/meta-iot2050/blob/master/conf/distro/debian-snapshot.list -- Siemens AG, Corporate Technology, CT RDA IOT SES-DE Corporate Competence Center Embedded Linux