I have never made any Apache release before, so it's probably good if someone more experienced does it the first time. So I would be grateful if Matt could do it.
I can maybe do it the next time. On Mar 8, 2017 5:43 PM, "Matt Sicker" <boa...@gmail.com> wrote: > If you don't have time to do it, Mikael, I could probably take care of it. > I'm planning on doing some Commons releases starting this week anyways, and > the process is fairly similar. > > On 8 March 2017 at 06:41, Apache <ralph.go...@dslextreme.com> wrote: > >> Yes, go for it. You can look at the Log4J release guide although some >> steps won't apply. >> >> Ralph >> >> On Mar 8, 2017, at 5:32 AM, Remko Popma <remko.po...@gmail.com> wrote: >> >> I won't be able to do it. :-) Why don't you give it a shot? I suspect you >> will be driving future changes often so it would be good if you can release >> such changes without having to wait for others to make time. >> >> Remko >> >> Sent from my iPhone >> >> On Mar 8, 2017, at 18:45, Mikael Ståldal <mikael.stal...@magine.com> >> wrote: >> >> OK, I have updated the log4j-scala repo to bump version to 11.0, and note >> in README about independent versioning. It should now be ready for release. >> Who will do the release? >> >> On Tue, Mar 7, 2017 at 8:06 PM, Ralph Goers <ralph.go...@dslextreme.com> >> wrote: >> >>> Yes. Scala should be released asap and the site manually modified to >>> point to it. We would then modify the log4j source to permanently point >>> there. >>> >>> Ralph >>> >>> On Mar 7, 2017, at 10:09 AM, Matt Sicker <boa...@gmail.com> wrote: >>> >>> Ralph pointed out that we can't make a release of the main repo without >>> the scala modules until there is a release of the scala modules on their >>> own. Otherwise, there'd be a regression in the main repo by removing >>> modules that were there before. >>> >>> On 7 March 2017 at 10:54, Remko Popma <remko.po...@gmail.com> wrote: >>> >>>> No objection from me to release log4j-scala. >>>> >>>> Do you have a versioning scheme that lets log4j-scala and log4j >>>> upgrade independently? >>>> >>>> Sent from my iPhone >>>> >>>> On Mar 8, 2017, at 1:42, Mikael Ståldal <mikael.stal...@magine.com> >>>> wrote: >>>> >>>> Can we release log4j-scala now? Or to we have to wait for the next >>>> release of main repo with Scala modules removed? Should we remove the Scala >>>> modules from main repo now? >>>> >>>> On Fri, Mar 3, 2017 at 5:16 PM, Matt Sicker <boa...@gmail.com> wrote: >>>> >>>>> The Scala language versions is already done the same standard way >>>>> everyone implements Scala libraries (hence the strange naming scheme we >>>>> already have). I'd imagine that the versions can be completely decoupled >>>>> by >>>>> specifying a minimum Log4j API version it requires (though should >>>>> generally >>>>> be whatever the latest was at release) and bumping its own version as new >>>>> features or bugfixes are added. I'd like to see that follow semantic >>>>> versioning properly, too. >>>>> >>>>> On 3 March 2017 at 06:15, Mikael Ståldal <mikael.stal...@magine.com> >>>>> wrote: >>>>> >>>>>> I guess the idea is that releases of Log4j 2 and log4j-scala should >>>>>> be independent in both ways, right? >>>>>> >>>>>> I think I have coordination between log4j-scala and Scala language >>>>>> covered already. >>>>>> >>>>>> On Fri, Mar 3, 2017 at 10:19 AM, Remko Popma <remko.po...@gmail.com> >>>>>> wrote: >>>>>> >>>>>>> Mikael, you probably need to plan your versioning scheme to handle >>>>>>> any combination of the following: >>>>>>> * log4j 2 releases: do you want to do a release for the log4j-scala >>>>>>> modules >>>>>>> every time? E.g., when we go from 2.8.1 to 2.8.2? My understanding is >>>>>>> that >>>>>>> once they are decoupled, the log4j-scala modules won't be released >>>>>>> automatically with log4j anymore, someone needs to do the work for >>>>>>> a log4j-scala release separately. >>>>>>> * Scala releases: how do you want to sync up with Scala language >>>>>>> versions? (I guess include major&minor Scala version in the log4j-scala >>>>>>> module version) >>>>>>> * log4j-scala module versions: enhancements to these modules, >>>>>>> independent of the above >>>>>>> >>>>>>> >>>>>>> Sent from my iPhone >>>>>>> >>>>>>> On Mar 3, 2017, at 9:10, Mikael Ståldal <mikael.stal...@magine.com> >>>>>>> wrote: >>>>>>> >>>>>>> I would like to keep package and artifact names, and bump version to >>>>>>> 11.0. >>>>>>> >>>>>>> On Mar 1, 2017 4:04 PM, "Matt Sicker" <boa...@gmail.com> wrote: >>>>>>> >>>>>>>> If you change artifact ids, it's generally a good idea to change >>>>>>>> packages, too. I've had issues in the past with Feign for instance >>>>>>>> because >>>>>>>> they changed groupId/artifactId at one point but kept the same API, so >>>>>>>> I >>>>>>>> had two copies on the classpath until I found out there was a >>>>>>>> duplicate and >>>>>>>> excluded them (though admittedly not a problem in OSGi environments >>>>>>>> :P). >>>>>>>> >>>>>>>> On 1 March 2017 at 07:47, Ralph Goers <ralph.go...@dslextreme.com> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> You can do that, but that will probably confuse users too. I would >>>>>>>>> suggest changing the artifactId and then start at either 1.0 or 2.0. >>>>>>>>> >>>>>>>>> Ralph >>>>>>>>> >>>>>>>>> On Mar 1, 2017, at 6:09 AM, Mikael Ståldal < >>>>>>>>> mikael.stal...@magine.com> wrote: >>>>>>>>> >>>>>>>>> OK, but then at least we have to start with a version > 2.8. >>>>>>>>> >>>>>>>>> On Wed, Mar 1, 2017 at 1:33 PM, Apache <ralph.go...@dslextreme.com >>>>>>>>> > wrote: >>>>>>>>> >>>>>>>>>> I guarantee if you try to keep the same versioning you will >>>>>>>>>> regret it. >>>>>>>>>> >>>>>>>>>> Ralph >>>>>>>>>> >>>>>>>>>> On Mar 1, 2017, at 2:22 AM, Mikael Ståldal < >>>>>>>>>> mikael.stal...@magine.com> wrote: >>>>>>>>>> >>>>>>>>>> I was under the impression that we were not ready to integrate >>>>>>>>>> the site from log4j-scala. That's why I considered the release of >>>>>>>>>> log4j-scala as delayed, since there is no point of releasing it if we >>>>>>>>>> cannot get the site integrated. >>>>>>>>>> >>>>>>>>>> But now when Ralph says he's ready to integrate the site, I guess >>>>>>>>>> we can go ahead and release log4j-scala. >>>>>>>>>> >>>>>>>>>> I don't like the idea of having separate versioning for >>>>>>>>>> log4j-scala, that will be confusing since we have already started >>>>>>>>>> with the >>>>>>>>>> same versioning as Log4j. Log4j-scala also have a dependency on >>>>>>>>>> log4j-api, >>>>>>>>>> and I think we want to keep that in sync. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Tue, Feb 28, 2017 at 4:08 PM, Matt Sicker <boa...@gmail.com> >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> One issue we came across in practice is that Scala 2.12 requires >>>>>>>>>>> Java 8, but we don't want to require that for the entire build, so >>>>>>>>>>> we >>>>>>>>>>> separated the repo. This also helps avoid making the main log4j >>>>>>>>>>> repo from >>>>>>>>>>> taking forever to build and release which can help the RERO idea. >>>>>>>>>>> Plus, >>>>>>>>>>> these non-core modules don't change nearly as often as log4j-core or >>>>>>>>>>> log4j-api, so they don't really need new releases all that often. >>>>>>>>>>> >>>>>>>>>>> On 28 February 2017 at 01:44, Remko Popma <remko.po...@gmail.com >>>>>>>>>>> > wrote: >>>>>>>>>>> >>>>>>>>>>>> To be honest I still don't understand >>>>>>>>>>>> >>>>>>>>>>>> * the vision of what we ultimately want to achieve >>>>>>>>>>>> * how different repos fit into that vision >>>>>>>>>>>> * what different websites we are planning to create to give >>>>>>>>>>>> users access to these different modules >>>>>>>>>>>> * what websites are going to be driven from which modules or >>>>>>>>>>>> projects >>>>>>>>>>>> * who of us is going to be driving what aspect of the above >>>>>>>>>>>> >>>>>>>>>>>> My lack of understanding is not just limited to the Scala >>>>>>>>>>>> modules but is about the whole splitting up the release. >>>>>>>>>>>> >>>>>>>>>>>> Perhaps a diagram would help clarify my understanding. (I think >>>>>>>>>>>> there's already a JIRA or an epic for the above. Adding some >>>>>>>>>>>> diagrams there >>>>>>>>>>>> would be very useful.) >>>>>>>>>>>> >>>>>>>>>>>> Remko >>>>>>>>>>>> >>>>>>>>>>>> On Tue, Feb 28, 2017 at 2:26 Matt Sicker <boa...@gmail.com> >>>>>>>>>>>> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> I'd be in favour of starting a new release train for the Log4j >>>>>>>>>>>>> Scala APIs. Not exactly sure which version to start from, though. >>>>>>>>>>>>> >>>>>>>>>>>>> On 27 February 2017 at 18:35, Ralph Goers < >>>>>>>>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> If you use that excuse they will never get released as it >>>>>>>>>>>>> creates a catch-22. If I release without them then we have a >>>>>>>>>>>>> regression >>>>>>>>>>>>> until they are released. >>>>>>>>>>>>> >>>>>>>>>>>>> This is why you shouldn’t really be releasing them using the >>>>>>>>>>>>> Log4j versions. Change the artifactIds so they can start at 1.0, >>>>>>>>>>>>> 2.0 or >>>>>>>>>>>>> whatever. >>>>>>>>>>>>> >>>>>>>>>>>>> Once you create the release and deploy it to the web site I >>>>>>>>>>>>> can modify the web site to point to it. >>>>>>>>>>>>> >>>>>>>>>>>>> Ralph >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 27, 2017, at 5:19 PM, Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Well, you included 2.10 and 2.11 in 2.8.1-rc1 which kind of >>>>>>>>>>>>> makes it harder to release from the log4j-scala repo when two of >>>>>>>>>>>>> the three >>>>>>>>>>>>> artifacts will already exist. >>>>>>>>>>>>> >>>>>>>>>>>>> On 27 February 2017 at 12:14, Ralph Goers < >>>>>>>>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Why is the release of log4j-scala delayed? >>>>>>>>>>>>> >>>>>>>>>>>>> Ralph >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 27, 2017, at 10:23 AM, Mikael Ståldal < >>>>>>>>>>>>> mikael.stal...@magine.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I would really like LOG4J2-1661 and LOG4J2-1690 out in the >>>>>>>>>>>>> next release. >>>>>>>>>>>>> >>>>>>>>>>>>> I implemented LOG4J2-1690 only in the new log4j-scala repo >>>>>>>>>>>>> since I thought that it would be released as part of 2.8, >>>>>>>>>>>>> otherwise I would >>>>>>>>>>>>> have put it to the main repo as well. But now releasing of the >>>>>>>>>>>>> log4j-scala >>>>>>>>>>>>> repo has been delayed and I start to get disappointed. >>>>>>>>>>>>> >>>>>>>>>>>>> On Sat, Feb 25, 2017 at 8:32 AM, Matt Sicker <boa...@gmail.com >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Relative symlinks would work for that regardless of version. >>>>>>>>>>>>> Option 1 it is, then? >>>>>>>>>>>>> >>>>>>>>>>>>> On 25 February 2017 at 00:22, Apache < >>>>>>>>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Note that the link in the log4j site can reference a symlink >>>>>>>>>>>>> so that the log4j site never has to change when the Scala site is >>>>>>>>>>>>> updated. >>>>>>>>>>>>> >>>>>>>>>>>>> Ralph >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 24, 2017, at 11:21 PM, Apache < >>>>>>>>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Option 2 makes no sense to me. I don’t plan on being the >>>>>>>>>>>>> release manager for log4j-scala. In order for me to implement >>>>>>>>>>>>> option 2 I >>>>>>>>>>>>> would have to include the log4j-scala site into the log4j release >>>>>>>>>>>>> process - >>>>>>>>>>>>> as well as log4j-examples, etc if they move out. That is just not >>>>>>>>>>>>> doable. >>>>>>>>>>>>> Deploying the Scala site parallel to log4j makes it much easier >>>>>>>>>>>>> to maintain >>>>>>>>>>>>> independently of log4j. >>>>>>>>>>>>> >>>>>>>>>>>>> Ralph >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 24, 2017, at 11:15 PM, Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> The site repository is laid out like this: >>>>>>>>>>>>> >>>>>>>>>>>>> log4j/2.x/ -(symlink)-> log4j-2.8/ >>>>>>>>>>>>> log4j/log4j-2.8/log4j-api/ >>>>>>>>>>>>> ... >>>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/ >>>>>>>>>>>>> >>>>>>>>>>>>> Option 1 is to put it here instead: >>>>>>>>>>>>> log4j/scala/2.x/log4j-api-scala_2.11/ (or some variant; >>>>>>>>>>>>> that's a pretty ugly URL honestly) >>>>>>>>>>>>> log4j/2.x/log4j-api-scala_2.11/ -(symlink)-> above directory >>>>>>>>>>>>> >>>>>>>>>>>>> Option 2 is to commit the scala site where it is now, but >>>>>>>>>>>>> you'd have to manage it alongside log4j core releases. Option 1 >>>>>>>>>>>>> still >>>>>>>>>>>>> requires maintenance, too. >>>>>>>>>>>>> >>>>>>>>>>>>> On 25 February 2017 at 00:05, Apache < >>>>>>>>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> There is a specific location in svn where the site pages have >>>>>>>>>>>>> to be committed, so I don’t really understand option 1. >>>>>>>>>>>>> >>>>>>>>>>>>> Ralph >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 24, 2017, at 9:48 PM, Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I see two ways of doing that, though: >>>>>>>>>>>>> >>>>>>>>>>>>> 1. Commit the Scala site in a separate directory similar to >>>>>>>>>>>>> what I started doing with Log4j Boot. Add redirect pages or >>>>>>>>>>>>> rewrite rules >>>>>>>>>>>>> via .htaccess if possible to keep links from breaking. >>>>>>>>>>>>> 2. Commit the Scala site where it would go when creating the >>>>>>>>>>>>> main site. Depending on how you update the files in svn for a >>>>>>>>>>>>> site update, >>>>>>>>>>>>> could this be more annoying to maintain? >>>>>>>>>>>>> >>>>>>>>>>>>> On 24 February 2017 at 22:30, Apache < >>>>>>>>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> From my perspective that doesn’t matter. However, we would >>>>>>>>>>>>> really need a Scala site before we can modify the Log4j site, >>>>>>>>>>>>> otherwise it >>>>>>>>>>>>> will be a dead link. >>>>>>>>>>>>> >>>>>>>>>>>>> All that really needs to happen is the Scala site needs to be >>>>>>>>>>>>> checked in adjacent to the Log4j 2 site. Then the Log4j 2 site >>>>>>>>>>>>> just has a >>>>>>>>>>>>> link to the Scala site from the main menu. The two sites won’t >>>>>>>>>>>>> really be >>>>>>>>>>>>> “integrated” - they will just have links to each other. >>>>>>>>>>>>> >>>>>>>>>>>>> Ralph >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 24, 2017, at 5:02 PM, Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> It is cosmetic, but we'd also be adding the Scala 2.12 module. >>>>>>>>>>>>> >>>>>>>>>>>>> On 24 February 2017 at 14:17, Apache < >>>>>>>>>>>>> ralph.go...@dslextreme.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I don’t have the numbers but I have a couple of issues that >>>>>>>>>>>>> need fixes. >>>>>>>>>>>>> >>>>>>>>>>>>> The modules stuff doesn’t require a major version bump. It is >>>>>>>>>>>>> mostly cosmetic. >>>>>>>>>>>>> >>>>>>>>>>>>> Ralph >>>>>>>>>>>>> >>>>>>>>>>>>> On Feb 24, 2017, at 12:41 PM, Gary Gregory < >>>>>>>>>>>>> garydgreg...@gmail.com> wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I think we can do 2.8.1 with our current bug fixes. Moving >>>>>>>>>>>>> modules around feels like a 2.9 item to me but that's just me. I >>>>>>>>>>>>> really >>>>>>>>>>>>> like the idea of making bug fixes available ASAP. The only issue >>>>>>>>>>>>> I see that >>>>>>>>>>>>> fixing now is the null classloader issue for which we have a >>>>>>>>>>>>> patch but it >>>>>>>>>>>>> does not work for me (see JIRA). >>>>>>>>>>>>> >>>>>>>>>>>>> Gary >>>>>>>>>>>>> >>>>>>>>>>>>> On Thu, Feb 23, 2017 at 8:07 PM, Matt Sicker <boa...@gmail.com >>>>>>>>>>>>> > wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I'm hoping we can get this released soon as we have some >>>>>>>>>>>>> bugfixes and such ready to go. I also want to move forward with >>>>>>>>>>>>> 2.9 changes >>>>>>>>>>>>> but don't really want to deal with creating a 2.9 branch or >>>>>>>>>>>>> forking master >>>>>>>>>>>>> into a 2.8 branch. Let's go over anything left to do for 2.8.1: >>>>>>>>>>>>> >>>>>>>>>>>>> * Integrated log4j-api-scala website into main site >>>>>>>>>>>>> * Remove scala modules from logging-log4j2 repo >>>>>>>>>>>>> * Release scala modules from logging-log4j-scala repo >>>>>>>>>>>>> (presumably shortly after releasing 2.8.1 of core?) >>>>>>>>>>>>> >>>>>>>>>>>>> I also have ideas on what we can shoot for in 2.9 and beyond, >>>>>>>>>>>>> but that's for another day. I think getting everything working >>>>>>>>>>>>> properly in >>>>>>>>>>>>> Java 9 would be a good thing to start doing soon so we can figure >>>>>>>>>>>>> out if >>>>>>>>>>>>> our APIs will still work properly in the future or if we need to >>>>>>>>>>>>> break >>>>>>>>>>>>> backwards compatibility. Although, multi-jar support could help in >>>>>>>>>>>>> migrating the API if needed for 9+, though that would be a rather >>>>>>>>>>>>> unorthodox abuse of the feature. >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> E-Mail: garydgreg...@gmail.com | ggreg...@apache.org >>>>>>>>>>>>> Java Persistence with Hibernate, Second Edition >>>>>>>>>>>>> <https://www.amazon.com/gp/product/1617290459/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1617290459&linkCode=as2&tag=garygregory-20&linkId=cadb800f39946ec62ea2b1af9fe6a2b8> >>>>>>>>>>>>> >>>>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1617290459> >>>>>>>>>>>>> JUnit in Action, Second Edition >>>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182021/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182021&linkCode=as2&tag=garygregory-20&linkId=31ecd1f6b6d1eaf8886ac902a24de418%22> >>>>>>>>>>>>> >>>>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182021> >>>>>>>>>>>>> Spring Batch in Action >>>>>>>>>>>>> <https://www.amazon.com/gp/product/1935182951/ref=as_li_tl?ie=UTF8&camp=1789&creative=9325&creativeASIN=1935182951&linkCode=%7B%7BlinkCode%7D%7D&tag=garygregory-20&linkId=%7B%7Blink_id%7D%7D%22%3ESpring+Batch+in+Action> >>>>>>>>>>>>> <http://ir-na.amazon-adsystem.com/e/ir?t=garygregory-20&l=am2&o=1&a=1935182951> >>>>>>>>>>>>> Blog: http://garygregory.wordpress.com >>>>>>>>>>>>> Home: http://garygregory.com/ >>>>>>>>>>>>> Tweet! http://twitter.com/GaryGregory >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Matt Sicker <boa...@gmail.com> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> ...
