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 <[email protected]>: >> 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 <[email protected]>: >>>> 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 <[email protected]>: >>>>>> 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 : [email protected] >>>>>> Unsubscribe : https://launchpad.net/~kicad-developers >>>>>> More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
