kicad-developers team mailing list archive

[Nick Østergaard <oe.nick@xxxxxxxxx>]

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