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.
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]>
