I think it'd be beneficial for our users if stage files included the appropriate profile version number, e.g.: stage3-amd64-13.0-20180107T214502Z.tar.xz This way our users would clearly know that our stages don't exactly correspond to the newest profiles available. Furthermore, I think we should be eventually building different stage versions at least for some time, and in that case the explicit version number would become necessary.
As for earlier requests about adding particular information regarding the build environment, I disagree with this proposal. In the past we've had requests to add to the name information regarding the configured march or the used gcc version. Also, I believe in Gentoo profiles were always seen as a way to "break forward", and not a way to keep development in parallel. Unless there's a global consensus about changing this, I propose we build 17.0 stages for now and do a few experimental stages with 17.1. Finally, one can always find the used profile by looking at the CONTENTS file. For the official amd64 stage3 from 20180109[1], we can find the profile[2] used was efault/linux/amd64/17.0 [1] - http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3-amd64/stage3-amd64-20180109T214501Z.tar.xz [2] - http://distfiles.gentoo.org/releases/amd64/autobuilds/current-stage3-amd64/stage3-amd64-20180109T214501Z.tar.xz.CONTENTS lrwxrwxrwx root/root 0 2018-01-10 00:47 ./etc/portage/make.profile -> ../../usr/portage/profiles/default/linux/amd64/17.0
Well, I'm not going to argue with you. For completeness, my use case was providing 17.0 and 17.1 stages for some time to cover the need of different recovery images for the systems.
(In reply to Michał Górny from comment #2) > Well, I'm not going to argue with you. For completeness, my use case was > providing 17.0 and 17.1 stages for some time to cover the need of different > recovery images for the systems. nope let's rather really always provide the newest one
