Closed anadahz closed 8 years ago
Are you sure a script is needed for doing this process? It seems like this is a fairly manual process that requires some level of human intelligence and I am not sure what benefit there is in automating it since at the end of the day you just need to update 1 file.
I wouldn't have made this script just for ChangeLog, though it is quite important to have a consistency in lepidopter_version
file that can be mistakenly set to a wrong version.
It seems like versioning information used to be stored inside of /etc/default/lepidopter
(https://github.com/TheTorProject/lepidopter/blob/master/lepidopter-vmdebootstrap_build.sh#L5), while now it's being written to /etc/lepidopter_version
. I would update this to write it to the same place and maintain consistency of the location and format of versioning information.
These files serve different purposes: /etc/default/lepidopter
stores a variable (LEPIDOPTER_BUILD
) of the git describe --tags
upon image build and /etc/lepidopter_version
contains only the git annotated tag object.
Similar to /etc/os-release
and /etc/debian_version
in Debian.
When would this file be updated? Is it only updated when a person installs by burning a new image or should it also updated by the updater?
The updater should update the /etc/lepidopter_version
file and should add a variable to /etc/default/lepidopter
in order to know that the specific lepidopter has been updated by the updater. I suggest not changing the LEPIDOPTER_BUILD
variable as this will help us to know the specific image build version of lepidopter and can help us alleviate future issues that may arise.
I'm going to proceed by merging this PR since it's what I'm using to build the test images.
This fixes #58.