Automate the release process about plfs-core HOT 5 CLOSED

Should the updates to VERSION and plfs.spec be checked in before tagging a release/release candidate?

from plfs-core.

Brett thinks we should update the VERSION file if we are using that to track the PLFS version.

We need to decide what, if any, RPM spec files we want to include. It seems to me that the contents of the spec file are site-specific. We may want to develop a source RPM spec file only.

from plfs-core.

So, do you mean that the modifications to the VERSION and RPM spec file should happen before a release is tagged? This would mean that rolling a release consists only of running autogen.sh, running configure, and then running 'make dist'.

from plfs-core.

I'm going to suggest that we let David Gunter workout what RPM spec file should be in the repository.

I don't know the purpose of the VERSION file. Please determine what its use is and then we'll decide what needs to get updated when for a release.

from plfs-core.

David Shrader notes: Automating the release process. We could put something in /scripts like /scripts/create_release, but it will be a very short script as all it should do is run autogen, configure and 'make dist'. Things like updating the VERSION file should have already been done in creating the release tag. I could see how a script that does the svn commands to create the release, change the VERSION file, commit the new release tag, run autogen, configure and 'make dist' would be helpful, but I don't think such a script should be committed to the PLFS source tree as it operates on more than a single instance of PLFS in the PLFS repository.

Brett Kettering notes: Let's close this and just leave it as it is now. If we come up with a better idea later, we'll pursue it.

from plfs-core.