You can also take a page out of JUnit's playbook. They release an "experimental" jar in each production release so you test out unfinished features before they become officially supported.
On Thu, Apr 17, 2014 at 4:41 PM, Gary Gregory <[email protected]>wrote: > 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 > -- Cheers, Paul
