incubator-general mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Harui <aha...@adobe.com>
Subject Re: Airflow voting on release artifacts
Date Wed, 26 Apr 2017 04:02:03 GMT


>
>3. There is no “separate” build script. Pip will just install a binary
>(“wheel”) or uses the source package (as shown above). Both are used
>interchangeable by users. We only distribute source packages at the
>moment.
>
>@Alex: I have to think a little bit more about what you wrote, but it is
>currently confusing the hell out of me :). Furthermore, I am not sure if
>it applies considering the above #3.

It could still apply.  You would just have to add a build script that
renames the package and metadata.

Let's say I wanted to release a single file that reported the version
number.  Forgive me that I don't know Python so I just grabbed what I
think it would look like from the internet.

---MyRelease.py---
print("I am version 1.2.3.")

Let's assume this is what your "customers" want to use.

I am proposing that the Apache Source Package also contain the following
file:

---BuildScript.sh---
# creates Customer Package in out folder.
mkdir out
sed s/1.2.3/1.2.3$1/ < MyRelease.py > out/MyRelease$1.py

Voters would run:

   BuildScript.sh RC1

That would result in:

---out/MyReleaseRC1.py---
print("I am version 1.2.3RC1.")

And this version would be tested by the voters.  The source package being
voted on contains the original MyRelease.py and BuildScript.sh.  The
release manager would also run:


    BuildScript.sh

That would result in:

---out/MyRelease.py---
print("I am version 1.2.3.")

In our project, the RM posts the source package in the RC folder and
creates a folder called "binaries" for the compiled source.  You could
call the folder something else, but let's keep the names for now.  The RM
would copy a zip of MyRelease.py and BuildScript.sh (and LICENSE, NOTICE,
README) into the RC folder and out/MyRelease.py to the "binaries" folder.
Along with signatures and checksum files.


Voters would download the zip, expand it, run "BuildScript.sh RC1" and
test with their out/MyReleaseRC1.py.  They would examine the zip to make
sure it is compliant with Apache release policy.  This is what all other
voters on all other projects generally do.  But they would perform one
different step, which is, instead of testing the MyRelease.py in the
"binaries" folder, they would simply diff their MyReleaseRC1.py against
the MyRelease.py in the "binaries" folder.  If the only diffs are the
version, they should feel satisfied that the resulting "customer" packages
is ok for release.

Of course, I could be wrong...

HTH,
-Alex

Mime
View raw message