Closed Bug 916791 Opened 11 years ago Closed 7 years ago

Rapid betas should not expire until several weeks after the release of the last beta

Categories

(Socorro :: General, task)

x86
macOS
task
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: brandon, Unassigned)

Details

On production, 24.0b expired on 2013-09-12, but it should not have expired for several more weeks after the last 24.0bx was released.
Right. What are the rules for expiry there right now?
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #1)
> Right. What are the rules for expiry there right now?

CREATE OR REPLACE FUNCTION sunset_date(build_id numeric, build_type citext) RETURNS date
    LANGUAGE sql IMMUTABLE
    AS $_$
-- sets a sunset date for visibility
-- based on a build number
-- current spec is 18 weeks for releases
-- 9 weeks for everything else
select ( build_date($1) +
    case when $2 = 'release'
        then interval '18 weeks'
    when $2 = 'ESR'
        then interval '18 weeks'
    else
        interval '9 weeks'
    end ) :: date
$_$;


We have a setting called 'sunset_date' on every entry in product_versions. This is what we had to update for B2G several weeks ago.
OK, so let's add and additional spec to the spec, if is_rapid_beta is true, we can make sunset_date be 12 weeks after the build_date, at least for the moment.
Ideally, we'd update it to always match the sunset_date of the last beta associated with that rapid beta.
Actually, has this been fixed to set them to matching already?

See this query:
breakpad=> SELECT version_string,build_date,sunset_date,is_rapid_beta,rapid_beta_id,product_version_id FROM product_versions WHERE product_name='Firefox' AND major_version='26.0';
 version_string | build_date | sunset_date | is_rapid_beta | rapid_beta_id | product_version_id 
----------------+------------+-------------+---------------+---------------+--------------------
 26.0a1         | 2013-08-06 | 2013-10-08  | f             |               |               1734
 26.0a2         | 2013-09-18 | 2013-11-20  | f             |               |               1829
 26.0b7         | 2013-11-22 | 2013-12-30  | f             |          1908 |               2000
 26.0b          | 2013-10-28 | 2013-12-30  | t             |               |               1908
 26.0b1         | 2013-10-28 | 2013-12-30  | f             |          1908 |               1911
 26.0b2         | 2013-11-04 | 2013-12-30  | f             |          1908 |               1928
 26.0b3         | 2013-11-07 | 2013-12-30  | f             |          1908 |               1935
 26.0b4         | 2013-11-11 | 2013-12-30  | f             |          1908 |               1941
 26.0b5         | 2013-11-14 | 2013-12-30  | f             |          1908 |               1988
 26.0b6         | 2013-11-18 | 2013-12-30  | f             |          1908 |               1996
 26.0b8         | 2013-11-25 | 2013-12-30  | f             |          1908 |               2002
 26.0b10        | 2013-12-02 | 2013-12-30  | f             |          1908 |               2009
 26.0           | 2013-12-02 | 2014-04-07  | f             |               |               2017
(13 rows)
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #4)
> Actually, has this been fixed to set them to matching already?
> 
> See this query:
> breakpad=> SELECT
> version_string,build_date,sunset_date,is_rapid_beta,rapid_beta_id,
> product_version_id FROM product_versions WHERE product_name='Firefox' AND
> major_version='26.0';
>  version_string | build_date | sunset_date | is_rapid_beta | rapid_beta_id |
> product_version_id 
> ----------------+------------+-------------+---------------+---------------+-
> -------------------
>  26.0a1         | 2013-08-06 | 2013-10-08  | f             |               |
> 1734
>  26.0a2         | 2013-09-18 | 2013-11-20  | f             |               |
> 1829
>  26.0b7         | 2013-11-22 | 2013-12-30  | f             |          1908 |
> 2000
>  26.0b          | 2013-10-28 | 2013-12-30  | t             |               |
> 1908
>  26.0b1         | 2013-10-28 | 2013-12-30  | f             |          1908 |
> 1911
>  26.0b2         | 2013-11-04 | 2013-12-30  | f             |          1908 |
> 1928
>  26.0b3         | 2013-11-07 | 2013-12-30  | f             |          1908 |
> 1935
>  26.0b4         | 2013-11-11 | 2013-12-30  | f             |          1908 |
> 1941
>  26.0b5         | 2013-11-14 | 2013-12-30  | f             |          1908 |
> 1988
>  26.0b6         | 2013-11-18 | 2013-12-30  | f             |          1908 |
> 1996
>  26.0b8         | 2013-11-25 | 2013-12-30  | f             |          1908 |
> 2002
>  26.0b10        | 2013-12-02 | 2013-12-30  | f             |          1908 |
> 2009
>  26.0           | 2013-12-02 | 2014-04-07  | f             |               |
> 2017
> (13 rows)

I may have done that in an earlier update...  I'll investigate further.
we appreciate our simple expiration policy
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.