Pre-Release Checklist for v6.2

25 views
Skip to first unread message

Ryan Culpepper

unread,
Apr 10, 2015, 1:02:16 PM4/10/15
to d...@racket-lang.org
Reminder: This is a practice release. The new release process is
described at:

https://github.com/plt/racket/wiki/Release-process

Checklist items for the v6.2 release
(using the v6.1.90.900 release candidate build)

Search for your name to find relevant items, reply when you finish an
item (please indicate which item/s is/are done). Also, if you have any
commits that should have been picked, make sure that the changes are in.

Important: new builds are created without announcement, usually whenever
I pick a few commits. If you need to commit changes, please make sure
you tell me to pick it into the release branch.

--> Release candidates are at
--> http://pre-release.racket-lang.org

Please use these installers (or source bundles) -- don't test from
your own git clone (don't test the `master' branch by mistake!). To
get the tests, you can do this:

cd ...racket-root...
./bin/raco pkg install -i main-distribution-test

----------------------------------------------------------------------

* Matthew Flatt <mfl...@cs.utah.edu>
- R6RS Tests
- Run the unix installer tests
Updates:
- Racket Updates: update HISTORY
(updates should show v6.2 as the most current version)

* Robby Findler <ro...@eecs.northwestern.edu>
- DrRacket Tests

* Sam Tobin-Hochstadt <sa...@ccs.neu.edu>,
Vincent St-Amour <stam...@ccs.neu.edu>
- Typed Racket Updates: update HISTORY
(updates should show v6.2 as the most current version; email me
to pick the changes when they're done, or tell me if there are no such
changes.)

* Matthias Felleisen <matt...@ccs.neu.edu>
- Teachpacks Tests: check that new teachpacks are addable
- Teachpack Docs: check teachpack docs in the bundles
- Try teaching-languages testing framework (check-expect)
Updates:
- Teachpack Updates: update HISTORY
(updates should show v6.2 as the most current version; email me
to pick the changes when they're done, or tell me if there are no such
changes.)

* Ryan Culpepper <ry...@ccs.neu.edu>
- Macro Debugger Tests
- syntax-parse Tests
- RackUnit GUI Tests
- Data Tests
- DB Tests
- Rackunit Tests
- SRFI Tests
Release tests for (one of the) linux releases:
- Test that the `racket' and `racket-textual' source releases
compile fine (note that they're still called `plt' and `mz' at
this stage).
- Test that the binary installers for both work, try each one in
both normal and unix-style installation modes. (just ubuntu)
[Note: get the release candidates from the URL in this email. Use
the 'static table' link to see a list of all tar files available]

* Stevie Strickland <sstr...@ccs.neu.edu>
- Unit Contract Tests
- Contract Region Tests
- Class Contract Tests

* Stephen Bloch <sbl...@adelphi.edu>
- Picturing Programs Tests

* David Van Horn <dvan...@ccs.neu.edu>
- EoPL Tests

* Neil Toronto <neil.t...@gmail.com>
- Plot Tests

* Doug Williams <m.douglas...@gmail.com>
- Additional Plot Tests

Matthew Flatt

unread,
Apr 10, 2015, 2:45:29 PM4/10/15
to Ryan Culpepper, d...@racket-lang.org
At Fri, 10 Apr 2015 13:02:09 -0400, Ryan Culpepper wrote:
> * Matthew Flatt <mfl...@cs.utah.edu>
> - R6RS Tests

The build includes the test repair that I made after the last attempt,
but I overlooked another test with exactly the same problem.

That mistake was fortunate, in a way, because it made me revisit the
Unicode specification to make sure that the test should change. I
discovered that the definition of "case-ignorable" has changed, and
Racket's update to Unicode 7.0 needs to be adjusted accordingly: an
apostrophe does not have the a MidLetter value, anymore, but its very
own Single_Quote value now counts as case-ignorable. It seems that the
old test was right after all, so I'll fix `string-titlecase` and revert
the test.

> - Run the unix installer tests

Failed, mainly due to timestamp issues in the build.

The bytecode files in "collects" for the distributions all have
timestamps of March 17. Is that intentional? That doesn't cause any
problems, but it seems strangely out of sync with the date that the
build must have happened.

The problem comes from the bytecode file for "scribble/xref.rkt" (in
the "scribble-lib" package) having a timestamp 12 seconds later than
the bytecode file for "setup/xref.rkt" (in the "racket-index" package),
even though "setup/xref.rkt" depends on "scribble/xref.rkt".


> Updates:
> - Racket Updates: update HISTORY

Done and already included in the build.

Matthias Felleisen

unread,
Apr 10, 2015, 4:26:17 PM4/10/15
to Ryan Culpepper, d...@racket-lang.org

On Apr 10, 2015, at 1:02 PM, Ryan Culpepper <ry...@ccs.neu.edu> wrote:

>
> * Matthias Felleisen <matt...@ccs.neu.edu>
> - Teachpacks Tests: check that new teachpacks are addable
> - Teachpack Docs: check teachpack docs in the bundles
> - Try teaching-languages testing framework (check-expect)
> Updates:
> - Teachpack Updates: update HISTORY
> (updates should show v6.2 as the most current version; email me
> to pick the changes when they're done, or tell me if there are no such
> changes.)


The build is broken. It does not include the push that Robby cherry-picked for me. -- Matthias

Robby Findler

unread,
Apr 10, 2015, 4:28:02 PM4/10/15
to Ryan Culpepper, d...@racket-lang.org
On Fri, Apr 10, 2015 at 12:02 PM, Ryan Culpepper <ry...@ccs.neu.edu> wrote:
> * Robby Findler <ro...@eecs.northwestern.edu>
> - DrRacket Tests

Done.

Robby Findler

unread,
Apr 10, 2015, 4:29:27 PM4/10/15
to Matthias Felleisen, Ryan Culpepper, d...@racket-lang.org
I think Matthias is referring to 5c0a07a7c in the release branch of
the htdp repo?

Robby
> --
> You received this message because you are subscribed to the Google Groups "Racket Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to racket-dev+...@googlegroups.com.
> To post to this group, send email to racke...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/racket-dev/F5E2B2A3-BE90-43B8-9CF3-BE983BC3E2B3%40ccs.neu.edu.
> For more options, visit https://groups.google.com/d/optout.

Ryan Culpepper

unread,
Apr 10, 2015, 7:46:13 PM4/10/15
to Matthew Flatt, d...@racket-lang.org

On Apr 10, 2015, at 2:45 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote:

> At Fri, 10 Apr 2015 13:02:09 -0400, Ryan Culpepper wrote:
>> * Matthew Flatt <mfl...@cs.utah.edu>
>> - R6RS Tests
>
> The build includes the test repair that I made after the last attempt,
> but I overlooked another test with exactly the same problem.
>
> That mistake was fortunate, in a way, because it made me revisit the
> Unicode specification to make sure that the test should change. I
> discovered that the definition of "case-ignorable" has changed, and
> Racket's update to Unicode 7.0 needs to be adjusted accordingly: an
> apostrophe does not have the a MidLetter value, anymore, but its very
> own Single_Quote value now counts as case-ignorable. It seems that the
> old test was right after all, so I'll fix `string-titlecase` and revert
> the test.
>
>> - Run the unix installer tests
>
> Failed, mainly due to timestamp issues in the build.
>
> The bytecode files in "collects" for the distributions all have
> timestamps of March 17. Is that intentional? That doesn't cause any
> problems, but it seems strangely out of sync with the date that the
> build must have happened.

There has been only one commit cherry-picked onto the main repository since the release branch was created that would have caused the recompilation of any zo files, and I usually don’t use the CLEAN flag for intermediate release candidates. (Should I?)

> The problem comes from the bytecode file for "scribble/xref.rkt" (in
> the "scribble-lib" package) having a timestamp 12 seconds later than
> the bytecode file for "setup/xref.rkt" (in the "racket-index" package),
> even though "setup/xref.rkt" depends on "scribble/xref.rkt”.

racket-index/setup/scribble.rkt is in fact the subject of that one commit. Is it possible that the build process caches built pkgs even when the timestamps of their dependencies change? A typical release build involves a “make site” followed by one or more “make installers-from-built” to deal with random problems (usually on Windows) followed by a “make site-from-installers”.

It’s also possible that I ran a previous build with cherry-picked changes on the local release branch but before pushing them to pltgit. Maybe that discrepancy caused the problem. I’ll try doing a build from a fresh checkout and see if that fixes the problem.

Ryan

Matthew Flatt

unread,
Apr 10, 2015, 10:01:33 PM4/10/15
to Ryan Culpepper, d...@racket-lang.org
At Fri, 10 Apr 2015 19:46:09 -0400, Ryan Culpepper wrote:
> On Apr 10, 2015, at 2:45 PM, Matthew Flatt <mfl...@cs.utah.edu> wrote:
> > At Fri, 10 Apr 2015 13:02:09 -0400, Ryan Culpepper wrote:
> > The bytecode files in "collects" for the distributions all have
> > timestamps of March 17. Is that intentional? That doesn't cause any
> > problems, but it seems strangely out of sync with the date that the
> > build must have happened.
>
> There has been only one commit cherry-picked onto the main repository
> since the release branch was created that would have caused the
> recompilation of any zo files, and I usually don’t use the CLEAN flag
> for intermediate release candidates. (Should I?)

Ah, a March 17 build makes sense then. You shouldn't have to use the
CLEAN flag.

> > The problem comes from the bytecode file for "scribble/xref.rkt" (in
> > the "scribble-lib" package) having a timestamp 12 seconds later than
> > the bytecode file for "setup/xref.rkt" (in the "racket-index" package),
> > even though "setup/xref.rkt" depends on "scribble/xref.rkt”.
>
> racket-index/setup/scribble.rkt is in fact the subject of that one
> commit. Is it possible that the build process caches built pkgs even
> when the timestamps of their dependencies change? A typical release
> build involves a “make site” followed by one or more “make
> installers-from-built” to deal with random problems (usually on
> Windows) followed by a “make site-from-installers”.
>
> It’s also possible that I ran a previous build with cherry-picked changes on
> the local release branch but before pushing them to pltgit. Maybe that
> discrepancy caused the problem. I’ll try doing a build from a fresh checkout
> and see if that fixes the problem.

All of that should work fine. The build process doesn't cache built
packages across different invocations of the package-building step.

The 12-second difference suggests something going wrong at a much finer
granularity, but I don't have any ideas right now.

Reply all
Reply to author
Forward
0 new messages