kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxx>]

The is mention of numbering in the stable release policy in the dev docs
but this was primarily aimed at the source release not the docs and
libraries.

On 12/10/2015 05:03 PM, Nick Østergaard wrote:
> I don't think we ever setteled on a real meaning of the numbers in the
> triplet version string. That should be documented, we might want to
> write a release procedure, since we have so many things to align. I
> will answer a bit more inline.
> 
> 2015-12-10 22:31 GMT+01:00 Wayne Stambaugh <stambaughw@xxxxxxxxx>:
>> Are you using a common revision tag for the source and the components?
>> If so we might want to rethink that.  I suppose you could change the tag
>> for 4.0.0 to 4.0.1 at the same commit but I'm guessing that would cause
>> other problems for package devs.
> 
> How can this be an issue for packagers? The packagers will just take
> the repo and reset to that version or take the tarballs for those.
> 
>> I would prefer the components to
>> remain the same all the way through the 4.0 series releases so they are
>> the same as the initial 4.0.0 release.
> 
> Why do we want this? If we just tag everything the same versions
> number, that will uniquely show that.
> 
>> It's early on so it there wont
>> be much of a difference now but at some point we are going to have new
>> features in the development branch that are documented that will have no
>> meaning in the 4.0 stable series.
> 
> Yes, that is natural, but what is the issue? Take the translations for
> example. We need to have some kind of string freeze to be able to
> reach 100% translations for the most active languages. So what we do;
> is that some time before we call a new release we can give translators
> time to translate for a week or two. I expect that the translators
> that want it to be 100% would be close to 100% translated at this
> time. Then they have a week or two to translate the rest.
> 
> One option is to physically enforce no string changes in the product
> branch and then let translators reach 100%, then tag it. Or just tag
> the source, and then give the translators some time, then they can tag
> the translations.  And the same for the other assets. When all are
> tagged, we can announce the release on the website.
> 
> But I think it makes most sense, and least confusion if we tag all
> repos the same.
> 
>> On 12/10/2015 3:40 PM, Nick Østergaard wrote:
>>> Why should we resuse the other things? We should at least tag
>>> everything as we did for 4.0.0, otherwise it will be a pain for
>>> packagers to package. They can't simply bump the package version and
>>> rebuild everything. I can have everything ready more or less now.
>>>
>>> 2015-12-10 1:48 GMT+01:00 Wayne Stambaugh <stambaughw@xxxxxxxxx>:
>>>> Please reuse the tagged 4.0 releases of the components.  The only thing
>>>> that should change are the binaries.
>>>>
>>>> Thanks,
>>>>
>>>> Wayne
>>>>
>>>> On 12/09/2015 06:30 PM, Nick Østergaard wrote:
>>>>> Hi Wayne
>>>>>
>>>>> Should we reuse the same releases of all the other components as is or
>>>>> take the tip?
>>>>>
>>>>> Thinking of kicad-doc, kicad-i18n, kicad-library, *.pretty.
>>>>>
>>>>> For a next backport at potential could be to include:
>>>>> http://bazaar.launchpad.net/~kicad-product-committers/kicad/product/revision/6362
>>>>>
>>>>> 2015-12-09 19:28 GMT+01:00 Wayne Stambaugh <stambaughw@xxxxxxxxx>:
>>>>>> I just pushed the 4.0.1 stable release so lets get those auto-builders
>>>>>> fired up to create packages for the latest release.
>>>>>>
>>>>>> Thanks,
>>>>>>
>>>>>> Wayne
>>>>>>
>>>>>> _______________________________________________
>>>>>> Mailing list: https://launchpad.net/~kicad-developers
>>>>>> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>>>>> More help   : https://help.launchpad.net/ListHelp