Hi Paul,
I really like the idea adding such info. I will add them soon. :-)
@Mahi,
I can help add such info for old releases and you can help to add them
from 2.5 then.
Thanks!
-------------------------------------------------------
Josh Cheng
Engineering Project Manager, Firefox OS
Mozilla Corporation
✉ [email protected] <mailto:[email protected]>
-------------------------------------------------------
> Paul Theriault <[email protected]> 於 2015年7月13日 上午11:41 寫道：
>
> If nothing else, can we at least add a notes to each branch description on
> https://wiki.mozilla.org/Release_Management/B2G_Landing
> <https://wiki.mozilla.org/Release_Management/B2G_Landing> which describes
> what the latest/final tagged version is?
>
> That might be a simple and flexible solution?
>
>
>> On 13 Jul 2015, at 12:40 am, Josh Cheng <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> Hi Christiane,
>>
>> Thanks for the proposal and I actually like the idea of adding FC/CC
>> (Release) tag. However, it might still hard for partners to determine
>> patches on the tagging because we still allow partner blockers to land after
>> CC. We might need another FINAL_RELEASE tag after we fix all partner
>> blockers.
>>
>> Anyway I think it wouldn’t hurt to add FC/CC tag for our internal planned
>> date for purpose as you mentioned: security advisories, release notes, other
>> technical editing, management decisions.
>>
>> Also CC Mahi(New RM) and Dylan if they have different opinion.
>>
>> Cheers,
>> -------------------------------------------------------
>> Josh Cheng
>> Engineering Project Manager, Firefox OS
>> Mozilla Corporation
>> ✉ [email protected] <mailto:[email protected]>
>> -------------------------------------------------------
>>
>>> Christiane Ruetten <[email protected] <mailto:[email protected]>> 於
>>> 2015年7月10日 下午10:02 寫道：
>>>
>>> I propose to introduce a specifically-named hg tag for B2G release
>>> versions that is created at or around release day, for example
>>> B2G_2_2_RELEASE.
>>>
>>> A consistent release tag can serve as anchor for security advisories,
>>> release notes, other technical editing, management decisions, and
>>> communication evolving around releases. It can also serve as reference
>>> for partners when it comes to updates and spotting backports.
>>>
>>> The current situation is that there are no specific release tags, just
>>> an ambivalent collection of *_MERGEDAY tags ( see
>>> http://hg.mozilla.org/releases/mozilla-b2g37_v2_2/
>>> <http://hg.mozilla.org/releases/mozilla-b2g37_v2_2/> ) which continues to
>>> accumulate over the maintenance cycle of a branch. This makes it hard to
>>> impossible to reliably determine which state our technical writing is
>>> referring to, especially when it comes to security advisories and what
>>> bug they cover per release.
>>>
>>> Even though Firefox has a different release model, their
>>> FIREFOX_BETA_*_END tags are equivalent to release tags.
>>>
>>>
>>> --
>>>
>>> Christiane Ruetten
>>> Mobile Malware Specialist
>>> Firefox OS Security
>>>
>>>
>>> _______________________________________________
>>> dev-b2g mailing list
>>> [email protected] <mailto:[email protected]>
>>> https://lists.mozilla.org/listinfo/dev-b2g
>>
>> _______________________________________________
>> dev-b2g mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.mozilla.org/listinfo/dev-b2g
>
_______________________________________________
dev-b2g mailing list
[email protected]
https://lists.mozilla.org/listinfo/dev-b2g
