canonical-ci-engineering team mailing list archive

[Vincent Ladeuil <vila+ci@xxxxxxxxxxxxx>]

>>>>> Francis Ginther <francis.ginther@xxxxxxxxxxxxx> writes:

    > Andy,
    > I was aware of this same-version limitation, but not of the specifics
    > as to why. We do need a mechanism to supply a version string that
    > always guarantees a higher version number. The cu2d tools do this
    > through a combination of a date stamp and iteration (i.e. 20131201.3)
    > appended to the package version. I don't know off the top of my head
    > how it keeps track of the iterations within a day, but it should be
    > possible to maintain this in some persistent storage (possibly within
    > the PPA Assigner itself).

Date may not be enough though, but if we add hour, minute, second, I
think we'll be just fine and won't have to handle an iteration that
requires persistence and therefore is harder. But there are probably
other constraints I'm not aware of so take that with a grain of salt. 

A caveat though, in distributed environments, there is no such thing as
a distributed and reliable clock. We may not care about that if all our
instances rely on ntp to provide a good enough clock, but the risk is
still there.

This is a critical piece to get right, it shouldn't be that hard to find
an always monotonically growing version scheme.

    > We do still need to perform a clean. For example: If we have a package
    > 'foo' on our build ppa with version 20131201.1, it will be promoted to
    > the archive PPA if it passes testing and used to create the golden
    > image. The next time a new 'foo' is attempted, it will have a higher
    > version, 20131201.2. If the testing for 'foo' fails, we need to delete
    > it so that when the build PPA is reused, the failed version of 'foo'
    > never gets integrated into a golden image. If the build PPA were not
    > cleaned, the 20131201.2 version would be selected instead of the
    > correct one in the archive PPA.

Agreed.

So let's use a version scheme that never produce the same version twice
so we don't have to constantly think about corner cases if we try to
reuse a version.

Note that an alternative is to use versions inside the ci engine alone
and always create a new version when a package can go to the "golden
image".

I realize this hasn't been thought about and I'm not proposing to switch
to that. Yet, it's something I'll keep thinking about as it will at
least split the problems around versions between internal and external
needs.

While we have to come up with a good versioning scheme, I don't think it
falls on the PPA assigner component responsibility, it's more likely to
be part of the Branch/Source builder one.

      Vincent