[WIP] Add Major.Minor release date to compiled assembly

[nulltoken]

The same way we currently use https://github.com/Particular/Timestamp to add a special attribute to an assembly.

The date needs to be:

• The first release date of a Major.Minor

Examples:
If we release v1.0.0 on 10 May 2014 then the Timestamp is 10 May 2014
If we release v1.0.1 on 12 May 2014 then the Timestamp is 10 May 2014 (same as v1.0.0)
If we release v1.0.1+x on 15 May 2014 then the Timestamp is 10 May 2014 (same as v1.0.0)

If we release v1.1.0 on 20 May 2014 then the Timestamp is 20 May 2014

[nulltoken]

As stated in Particular/NServiceBus#1968 the initial requirement would be "to provide hotfixes for older versions we need to keep the date stable within the same Major.Minor (ie use the date of the first release)".

As discussed with @andreasohlund, the idea would be to modify the AssemblyInfoBuilder to make it generate an assembly ReleaseDateAttribute with two properties Date and OriginalDate.

The OriginalDate would be retrieved from the latest stable (tagged x.y.0) commit on master reachable from the commit being built.

So, here's a first draft. One of the added tests (temporarily) dumps some version information per commit.

The test repository is the same than the one described in #79

    hotfix-1.2.1       -----------C--      
                      /              \     
    master           A----------------F-----H-------N
                      \                    / \     /
    hotfix-1.3.1       \                  /   ----L
                        \                /         \
    release-1.3.0        \        -D----G---        \
                          \      /          \        \
    develop                -----B----E-------I-----M--O--P
                                      \           /
    feature                            -------J-K-

• A is tagged 1.2.0
• F is tagged 1.2.1
• H is tagged 1.3.0
• N is tagged 1.3.1

Below is a list of the latest reachable stable commits on master that should be used in order to extract the original release date.

This reads as "When building Commit X (from branch Y), I should consider the commit pointed by VersionPoint major.minor.sha to identify the original release date.".

• Commit P (develop) => VersionPoint 1.3.5b84136c848fd48f1f8b3fa4e1b767a1f6101279
• Commit O (develop) => VersionPoint 1.3.5b84136c848fd48f1f8b3fa4e1b767a1f6101279
• Commit N (master) => VersionPoint 1.3.5b84136c848fd48f1f8b3fa4e1b767a1f6101279
• Commit M (develop) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
• Commit L (hotfix-1.3.1) = > VersionPoint 1.3.5b84136c848fd48f1f8b3fa4e1b767a1f6101279
• Commit K (feature) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
• Commit J (feature) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
• Commit I (develop) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
• Commit H (master) => VersionPoint 1.3.5b84136c848fd48f1f8b3fa4e1b767a1f6101279
• Commit G (release-1.3.0) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
• Commit F (master) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
• Commit E (develop) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
• Commit D (release-1.3.0) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
• Commit C (hotfix-1.2.1) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
• Commit B (develop) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908

Although it seems to be working as expected for hotfixes, I'm not sure that this makes sense for the other branches. For instance, Commits I and K would rely on v1.2 whereas v1.3 would have been already released with commit H.

However, I'm not sure to understand what would the OriginalDate concept represent from a "feature" or "release" branch perspective...

I can think of two paths from here:

• Dropping the "reachable" constraint to come up with OriginalDate values more in line with the latest state of "master" and make the OriginalDate concept available for every kind of builds
• Restricting the generation of the ReleaseDateAttribute to "master" and "hotfix" branches

Thoughts?

[andreasohlund]

Since OrigininalDate is only relevant on master+hotfix I propose the following:

Always generate the attribute with the Date property set to date of commit

If last digit in semver isn't 0 (ie hotfix) go and find the corresponding merge/label on master to populate the OriginalDate property. Throw if not found

If last digit is 0 set OriginalDate=Date

For githubflow OriginalDate always == Date

Thoughts?

Sent from my iPhone

On 28 feb 2014, at 23:34, nulltoken [email protected] wrote:

As stated in Particular/NServiceBus#1968 the initial requirement would be "to provide hotfixes for older versions we need to keep the date stable within the same Major.Minor (ie use the date of the first release)".

As discussed with @andreasohlund, the idea would be to modify the AssemblyInfoBuilder to make it generate an assembly ReleaseDateAttribute with two properties Date and OriginalDate.

The OriginalDate would be retrieved from the latest stable (tagged x.y.0) commit on master reachable from the commit being built.

So, here's a first draft. One of the added tests (temporarily) dumps some version information per commit.

The test repository is the same than the one described in #79

hotfix-1.2.1       -----------C--      
                  /              \     
master           A----------------F-----H-------N
                  \                    / \     /
hotfix-1.3.1       \                  /   ----L
                    \                /         \
release-1.3.0        \        -D----G---        \
                      \      /          \        \
develop                -----B----E-------I-----M--O--P
                                  \           /
feature                            -------J-K-

A is tagged 1.2.0
F is tagged 1.2.1
H is tagged 1.3.0
N is tagged 1.3.1
Below is a list of the latest reachable stable commits on master that should be used in order to extract the original release date.

This reads as "When building Commit X (from branch Y), I should consider the commit pointed by VersionPoint major.minor.sha to identify the original release date.".

Commit P (develop) => VersionPoint 1.3.5b84136c848fd48f1f8b3fa4e1b767a1f6101279
Commit O (develop) => VersionPoint 1.3.5b84136c848fd48f1f8b3fa4e1b767a1f6101279
Commit N (master) => VersionPoint 1.3.5b84136c848fd48f1f8b3fa4e1b767a1f6101279
Commit M (develop) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
Commit L (hotfix-1.3.1) = > VersionPoint 1.3.5b84136c848fd48f1f8b3fa4e1b767a1f6101279
Commit K (feature) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
Commit J (feature) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
Commit I (develop) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
Commit H (master) => VersionPoint 1.3.5b84136c848fd48f1f8b3fa4e1b767a1f6101279
Commit G (release-1.3.0) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
Commit F (master) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
Commit E (develop) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
Commit D (release-1.3.0) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
Commit C (hotfix-1.2.1) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
Commit B (develop) => VersionPoint 1.2.8c890487ed143d5a72d151e64be1c5ddb314c908
Although it seems to be working as expected for hotfixes, I'm not sure that this makes sense for the other branches. For instance, Commits I and K would rely on v1.2 whereas v1.3 would have been already released with commit H.

However, I'm not sure to understand what would the OriginalDate concept represent from a "feature" or "release" branch perspective...

I can think of two paths from here:

Dropping the "reachable" constraint to come up with OriginalDate values more in line with the latest state of "master" and make the OriginalDate concept available for every kind of builds
Restricting the generation of the ReleaseDateAttribute to "master" and "hotfix" branches
Thoughts?

—
Reply to this email directly or view it on GitHub.

[SimonCropp]

@andreasohlund i like it. and that simplifies the problem

[nulltoken]

@andreasohlund First alpha release. With generation of the ReleaseDate attribute.

Proposed next steps:

• Gather feedback
• Fix reported issues
• Cleanup commit history
• Cover with tests in a different PR

[andreasohlund]

@nulltoken works as expected.

[andreasohlund]

What is the next steps? (can you cleanup so that we can pull?)

[andreasohlund]

@nulltoken as discussed, go ahead and squash

[nulltoken]

@andreasohlund Done. As I cleaned up the history and this feature is not backed up by tests, could you do a final pass of testing to make sure I didn't mess up anything, please?

[andreasohlund]

Done, looks good!

Sent from my iPhone

On 7 mar 2014, at 17:13, nulltoken [email protected] wrote:

@andreasohlund Done. As I cleaned up the history and this feature is not backed up by tests, could you do a final pass of testing to make sure I didn't mess up anything, please?

—
Reply to this email directly or view it on GitHub.