![]() Repackage and upload additional tools where needed. ![]() Check version of the above mentioned tools (GNU tools, helper DLLs, UPX, etc.), and decide whether it isn't time to update some of these tools.Later the final release sections has to be added. New page in Wiki for release procedure with steps needed and their status (this page), at the beginning consisting of the beta (2.1.) release.These things has to be done only once for each release-cycle. These two pages should be eventually merged (or probably rather better interlinked) in the future. Note that detailed information for some tasks can be found in Release engineering. If we are lucky, the release of 2.1.4 can be in the week thereafter. If things go well, 2.1.4 will be tagged friday the 30th.Friday the 16th version 2.1.2 will be tagged from the fixes_2_2 branch.Merging patches should be done by the developers who are 'responsible' for that part of the code. Is the release canidates are satisfactory, 2.2.0 will be released.About two months after version 2.1.4, there will be (at least one) release candidate for version 2.2.0.From the release of 2.1.4 on, no new features will be added and no functionality will be removed. Version 2.1.4 will be public and announced.In principle between version 2.1.2 and 2.1.4 only build-related patches are allowed. ![]() The release of 2.1.2 is the 'feature freeze' for version 2.2.0.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |