Tuesday, October 3, 2017, 2:19:49 AM, Woonsan Ko wrote: > Hi Daniel, > > I've passed along to the step #9 > (https://dist.apache.org/repos/dist/dev/incubator/freemarker/engine/2.3.27-incubating/),
A small thing, but we better not use the same path for this preliminary review than for the later voting. Like let's add "-preliminary" to directory name. > except of GAE release artifacts. What is the ant command to build GAE > release artifacts? Same as for the non-GAE branch, but you issue them from the directory of the 2.3-gae branch. (Note that the artifact names differ.) mavenVersion=2.3.27-incubating-SNAPSHOT shouldn't contain "-SNAPSHOT" for the final release. Note that gpg --verify shows a warning because your signature is not signed by anyone else. Not a show stopper as we have discussed, just FYI. > Also, here's the result of JAPICC: > > Preparing, please wait ... > WARNING: set #1 version number to 2.3.26 (use --v1=NUM option to change it) > Using Java 1.8.0_144 > Reading classes 2.3.26 ... > WARNING: set #2 version number to 2.3.27 (use --v2=NUM option to change it) > Reading classes 2.3.27 ... > Comparing classes ... > Creating compatibility report ... > Binary compatibility: 99.9% > Source compatibility: 99.9% > Total binary compatibility problems: 1, warnings: 0 > Total source compatibility problems: 1, warnings: 0 > Report: compat_reports/FreeMarker/2.3.26_to_2.3.27/compat_report.html > > The 'problem' in the html report is as follows: > "Type of field EMPTY_HASH has been changed from > freemarker.template.TemplateHashModelEx to > freemarker.template.TemplateHashModelEx2." > > It seems like a false alarm since I cannot find EMPTY_HASH field in > each file and in each version. It's in freemarker.template.utility.Constants, and the alarm is right, that breaks binary compatibility. (Linking doesn't allow a subtype instead of the type referred from the class file.) I have committed the fix. > Regards, > > Woonsan > > On Mon, Oct 2, 2017 at 11:39 AM, Daniel Dekany <[email protected]> wrote: >> Monday, October 2, 2017, 5:19:11 PM, Woonsan Ko wrote: >> >>> Hi Daniel, >>> >>> I have two questions regarding the release steps. >>> >>> 1. Are we supposed to release an RC version ("rc01") now? >> >> I say, no, the changes weren't significant enough, we go for 2.3.27 >> straight. But it will be important (as always, actually...) to check >> the binary API compatibility report carefully. >> >> Also, it will be important that others (like OFBiz and Moqui devs) try >> their real world application with the new version artifacts. >> >>> 2. In version.properties of 2.3 branch, do we need to update these only? >>> >>> version=2.3.27-rc01-incubating >>> mavenVersion=2.3.27-incubating-SNAPSHOT # <-- no change here >>> versionForOSGi=2.3.27.rc01-incubating >>> versionForMf=2.3.26.99 >> >> Yes, but to non-RC now. >> >>> Thanks in advance, >>> >>> Woonsan >>> >>> >>> On Mon, Oct 2, 2017 at 5:06 AM, Daniel Dekany <[email protected]> wrote: >>>> Monday, October 2, 2017, 5:39:40 AM, Woonsan Ko wrote: >>>> >>>>> On Sat, Sep 30, 2017 at 6:28 AM, Daniel Dekany <[email protected]> wrote: >>>>>> Saturday, September 30, 2017, 3:39:24 AM, Woonsan Ko wrote: >>>>>> >>>>>>> On Mon, Sep 25, 2017 at 2:49 PM, Daniel Dekany <[email protected]> >>>>>>> wrote: >>>>>>>> Monday, September 25, 2017, 7:23:14 PM, Woonsan Ko wrote: >>>>>>>> >>>>>>>>> I'd like to volunteer for that. >>>>>>>>> Assuming there's a voting process, I guess the release process will >>>>>>>>> happen next week or afterward, right? >>>>>>>> >>>>>>>> The actual release yes, but the duty of the Release Manager is to take >>>>>>>> care of the whole process. That's starting with checking if the thing >>>>>>>> is ready and publishing it internally for a preview, then achieving >>>>>>>> community consensus (which for us means a voting on dev@freemarker, >>>>>>>> and if that passes then another voting on general@incubator), then >>>>>>>> actually pushing the distribution. But >>>>>>>> http://freemarker.org/committer-howto.html#making-releases describes >>>>>>>> all these steps. (There are also official resources like >>>>>>>> http://www.apache.org/dev/#releases and >>>>>>>> http://incubator.apache.org/guides/releasemanagement.html, but the >>>>>>>> point of the how-to is that you don't have to read them.) >>>>>>>> >>>>>>>> As you will note if you read the above, you will need a PGP signature >>>>>>>> and certain rights to commit into some repos and to do things on >>>>>>>> Nexus. So you will have to start with requesting those rights. >>>>>>> >>>>>>> I've added mine to KEYS files in >>>>>>> dist.apache.org/repos/dist/{dev,release}/incubator/freemarker/. >>>>>> >>>>>> I'm not a PGP expert at all, so I really don't know if these have any >>>>>> practical implications, but two things that I'm not sure about: >>>>>> >>>>>> - Wouldn't it be better to stick to only one of the two public keys? >>>>> >>>>> I've reverted the previous addition and added the latest one only again: >>>>> - https://dist.apache.org/repos/dist/dev/incubator/freemarker/KEYS >>>>> - https://dist.apache.org/repos/dist/release/incubator/freemarker/KEYS >>>> >>>> OK >>>> >>>>>> - The pub header in KEYS looks kind of unusual. It used to be like >>>>>> "pub 4096R/82667DC1 2014-07-17", where the 82667DC1 is used on >>>>>> several places to refer to the public key, like in sig-s and all. >>>>> >>>>> I don't know. I used the same command as shown in KEYS file: >>>>> (gpg --list-sigs 04...CE && gpg --armor --export 04...CE) >> KEYS >>>> >>>> Then I will assume then it's fine until somebody complains... It's not >>>> a blocker in an case, since KEYS is not part of the release. >>>> >>>>> Does anyone know the differences? >>>> >>>>>> Last not least, someone from the ASF who knows you in person should >>>>>> sign the key that you release with. The Ring of Trust thing, you >>>>>> know... (I guess it's good enough if I do it, when the above key >>>>>> question is settled.) >>>>> >>>>> I'm not sure if it is required. In my experiences, it is good enough >>>>> to register your public key in one of the most popular key server as >>>>> the Nexus checks it from it, like Apache releases are usually >>>>> verified. [1] >>>>> - >>>>> http://pgp.mit.edu/pks/lookup?search=Woonsan+Ko&op=index&fingerprint=on >>>> >>>> I'm not aware of a formal requirement either, but maybe some on >>>> general@incubator won't like it. Anyway, it doesn't block the release >>>> process, as it can be signed any time later (as it doesn't affect your >>>> key pair, it doesn't affect the signed artifact... I think). >>>> >>>>> Regards, >>>>> >>>>> Woonsan >>>>> >>>>> [1] https://www.apache.org/info/verification.html#CheckingSignatures >>>>> >>>>>> >>>>>>> And, I was able to log on the Nexus and browse repository and staging >>>>>>> repository. >>>>>>> The next is to follow "The steps of making a release" section? >>>>>> >>>>>> I'm just investigating some backward compatibility issue, but >>>>>> otherwise yes. (I have updated it a bit BTW.) Are you using some kind >>>>>> of instant messaging or chat room or such? E-mail will be too slow I >>>>>> think. (Screen sharing and voice can come handy as well sometimes. If >>>>>> you happen to use Skype, I'm there.) >>>>>> >>>>>> >>>>>>> Regards, >>>>>>> >>>>>>> Woonsan >>>>>>> >>>>>>>> >>>>>>>>> I'm asking this because my laptop got broken before the last week >>>>>>>>> and I'm waiting for a new laptop to be delivered this week. If it is >>>>>>>>> next week or afterward, I'll be prepared properly. >>>>>>>> >>>>>>>> If in the light of the above you are still willing to do this, I will >>>>>>>> wait. >>>>>>>> >>>>>>>>> Regards, >>>>>>>>> >>>>>>>>> Woonsan >>>>>>>>> >>>>>>>>> On Wed, Sep 20, 2017 at 2:12 PM, Daniel Dekany <[email protected]> >>>>>>>>> wrote: >>>>>>>>>> Could somebody with commit rights volunteer for this? We have a >>>>>>>>>> step-to-step guide >>>>>>>>>> (http://freemarker.org/committer-howto.html#making-releases), and I >>>>>>>>>> would be present to help with this (through Skype or whatever you >>>>>>>>>> prefer). I want to see (and demonstrate) that in case I'm gone >>>>>>>>>> someone >>>>>>>>>> else can do a release. >>>>>>>>>> >>>>>>>>>> Thanks a lot! >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Best regards, >>>>>>>>>> Daniel Dekany >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Thanks, >>>>>>>> Daniel Dekany >>>>>>>> >>>>>>> >>>>>> >>>>>> -- >>>>>> Thanks, >>>>>> Daniel Dekany >>>>>> >>>>> >>>> >>>> -- >>>> Thanks, >>>> Daniel Dekany >>>> >>> >> >> -- >> Thanks, >> Daniel Dekany >> > -- Thanks, Daniel Dekany
