search

apache / incubator-pagespeed-ngx

Automatic PageSpeed optimization module for Nginx
http://ngxpagespeed.com/
Apache License 2.0
4.37k stars 363 forks source link

Version 1.11.3.3 released without updating the code #1246

Open nikolay opened 8 years ago

nikolay commented 8 years ago

https://github.com/pagespeed/ngx_pagespeed/releases/tag/v1.11.33.3-beta but it's missing something similar to: https://github.com/pagespeed/ngx_pagespeed/commit/b26e174d8bcce7b0d73d0afb5f8229a812806dea

oschaaf commented 8 years ago

I have not seen an announcement yet [1], so it looks like 1.11.33.3-beta is still a work in progress.

[1] https://groups.google.com/forum/#!forum/ngx-pagespeed-announce https://developers.google.com/speed/pagespeed/module/release_notes

crowell commented 8 years ago

we're still getting everything finalized for the release which should be out shortly!

nikolay commented 8 years ago

How can we differentiate between a "released" and "unreleased" versions then? As far as I know, there's a way to properly cut out a release and mark it as a "pre-release": https://help.github.com/articles/creating-releases/

centminmod commented 8 years ago

released is whenever it's announced at https://groups.google.com/forum/#!forum/ngx-pagespeed-announce AFAIK

nikolay commented 8 years ago

@centminmod Yeah, if you're a sorry human; if you're a CI system that tests against the release a, there need to be some indication.

crowell commented 8 years ago

@nikolay the "releases" on github get autogenerated on tags (I haven't touched the github "releases" menu for this release for example), which isn't really ideal for us as everything can't be done atomically (updating nginx and apache modules and their distribution system requires a bit of coordination).

jmarantz commented 8 years ago

I'm not sure I understand the details RE git, but the request of having a mechanical way to determine what the most recent release is without monitoring emails is a reasonable one.

OTOH if a CI system hiccups and generates a non-working build during a limited-time window of vulnerability in our release process, this seems non-fatal as long as it recovers once all is updated. Is that right?

Maybe we can do something simple like write the updated latest beta and stable tags into a trunk files, and update those trunk files only when the release is complete. CI systems could read those files to figure out which tag to use.

nikolay commented 8 years ago

@crowell Those aren't true releases, which are created via the API, CLI, or the web interface.