Initial Expeditor configuration for updating CHANGELOG.md

[sajjaphani]

Expeditor configuration for updating CHANGELOG.md

Signed-off-by: Phani Sajja psajja@progress.com

[mwrock]

My concern here is that the VERSION 2022-02-10 would be less than our current versions on bldr which are 9xxx. If we are going to start a new version scheme its going to have to be later than what is in stable now. While it feels terrible, maybe having VERSION be 12000 is what we have to start with. In any case we will need to update our plan files as well to use VERSION instead of git log. I'm not certain, but we may also need to setup expeditor channels, as proposed in #1707 so that changes get properly rolled up after a promotion.

[mwrock]

so actually now that I think of it, maybe what you are getting at here is maintaining VERSION simply for changelog purposes. At least for now that might be the best approach. I'm not sure how/if that will work with the changelog automation but its probably worth merging this to find out. It can't hurt anything.

[mwrock]

I wonder how this is going to work with the date format? Maybe we shouldn't have expeditor auto bump and only we bump the version prior to release?

[sajjaphani]

Yeah, the behavior may be undefined here as we do not have a semantic version in the VERSION file.
What is the result of removing the action: built_in:bump_version. Is it going to add an entry into the change log and use the version specified in the VERSION file?

We can bump the version on the release date if the above works for us.

The other option is to start using the semantic version 1.0.0 for the builder.

[sajjaphani]

so actually now that I think of it, maybe what you are getting at here is maintaining VERSION simply for changelog purposes. At least for now that might be the best approach. I'm not sure how/if that will work with the changelog automation but its probably worth merging this to find out. It can't hurt anything.

We started publishing the builder changes based on the date. I think it may not be a bad idea to start the builder with semantic versioning 1.0.0 and let expeditor bump the version.

[mwrock]

I kind of like the date more. If we move to semantic versioning, I think we need to make that change to the packages as well and not just the change log. In which case we need to start with 12000.0 which seems weird. I'm not sure exactly how the changelog automation will behabe if we remove built_in:bump_version but I think that will keep it from trying to create a 2022-02-23.1 and so on. We'll probably have to merge something and experiment but I'm hoping that when we want to release, we just change the VERSION to the new data and then expeditor rolls up the changelog correctly. That could be wishful thinking (most of my thinking really).

[mwrock]

I think we should make this 20220210 so that latest will honor these versions. I think (not 100%) thta 2022-02-10 would not be latest

[sajjaphani]

Still, that is the last time we released the builder.