On Thu, Apr 17, 2014 at 4:22 PM, Ralph Goers <[email protected]>wrote:
> 1. I prefer trunk to be the stable branch. In addition to the 2.0 tag I > would also cut a branch when 2.0 is finally released. > +1, ideally we can cut releases at any time out of trunk for log4j. Experimentation can be done in branches. Gary > > 2. I could swear we have always generated the OSGi MANIFEST.MF and people > said it wasn’t sufficient, but if they aren’t there then I guess I am wrong. > > 3. I would like to see a list of what would be broken out before we > actually do it. > > 4. I’d like to see 2.0 GA asap, so I agree. > > 5. A release can be cut at any time. We don’t vote to perform a release, > we vote that the release is good to go public. > > 6. The Marker stuff is done, except for removing the deprecated APIs. We > need to finalize the logo. I don’t know if any outstanding issues are > blockers. > > Ralph > > > > On Apr 17, 2014, at 10:51 AM, Matt Sicker <[email protected]> wrote: > > I've got a few topics to mention. > > 1. Should we consider making a 2.0 release branch so that trunk can > continue to be the active development branch? That way we can work on new > things while just ironing out the remaining issues for 2.0 GA in the 2.0 > branch. Unless you guys prefer a different branching workflow like trunk > being the stable branch, and then using feature branches. > > 2. OSGi support. What I'm thinking will be the easiest way to get this > working correctly without having to worry so much about duplicating bundles > would be to simply drop the log4j-osgi modules and just add the OSGi > MANIFEST.MF metadata to our normal releases. This would effectively be good > enough for supporting OSGi bundles in that regard. We can figure out how to > trim down log4j-core independently of anything OSGi. I've already began > work on this by updating the poms for log4j, log4j-api, and log4j-1.2-api. > I'll update the other smaller modules to reflect the updated build process > as well. There may be a slight issue with the log4j-slf4j-impl module due > to how SLF4J expects implementations to be packaged, so I'll take a look > into that as well (and possibly go complain to them if necessary). In fact, > supporting OSGi for some of these modules might not be possible due to > package splits and backwards compatibility. > > 3. Essentially, I'm thinking that we could separate out all the parts of > log4j-core that use external dependencies with the exception of AsyncLogger > (we could potentially fork lmax-disruptor into our own repository similar > to how Tomcat handles some of their dependencies). That way, we don't need > to worry about optional dependencies, either, because when they're split > up, the new modules can have required dependencies instead (whether it be > an API or a concrete library). If there are any other parts of log4j-core > that rely on external dependencies that we think are popular enough to keep > in log4j-core, please share. > > 4. Due to how new these modules are, I'm proposing that log4j-streams and > log4j-camel both be slated for release in 2.1 or some future release. > Otherwise, these might hold back our 2.0 release a little bit. Where we > place the code depends on (1) (keep in trunk or make feature branches). Of > course, both modules are independently up for vote on whether to include > them in 2.0. Since I added the log4j-camel module as a sort of experimental > module largely based on the log module in camel-core (which uses SLF4J > instead), I'd like to see this part in 2.1, but not in 2.0 since I've > barely tested it yet (and still need to port more tests to it along with > some integration testing). > > 5. After addressing the modules thing from (3), we should probably vote on > an RC2 release sometime soon. I'd propose releasing RC2 in the beginning of > May, but I'm open for whenever. > > 6. What else is left for 2.0? The updated Marker API is almost complete > (we have our own code that needs to be updated to not use the deprecated > APIs, but that might only be unit tests at this point). > -- > Matt Sicker <[email protected]> > > > -- E-Mail: [email protected] | [email protected] Java Persistence with Hibernate, Second Edition<http://www.manning.com/bauer3/> JUnit in Action, Second Edition <http://www.manning.com/tahchiev/> Spring Batch in Action <http://www.manning.com/templier/> Blog: http://garygregory.wordpress.com Home: http://garygregory.com/ Tweet! http://twitter.com/GaryGregory
