Hi Murray, currently we don't have any "official" way of working with branches other than master should be releasable at any given moment. Note that this doesn't mean feature-complete, but releasable.
Given that the pace of development is slow, most of the time the commits go directly to master, using other branches for changes that affect most of the codebase, to discuss them (and IIRC there've only been a couple so far..) Development is quite behind master, I'd say it haven't been used on a long time. It is much safer to start, or branch, from master, which btw currently uses JDK8. Also, almost a year (?) ago we began to follow a release train model, meaning we should be able to release master every three months. Speaking of that, november is a release month so more sooner than later we should begin a [VOTE] for the new version. As for versions, we're in the middle of switching to 2.11, meaning breaking changes from 2.10 would be allowed. But, instead of releasing 2.11.0, we're going with release 2.11.0.M1, 2.11.0.M2, etc (don't know how may milestones). The idea there is that M# releases would allow us to keep breaking compatibility with 2.10 within several releases, but other than that should be as ready for production as normal releases. Currently, the following breaking changes from 2.10 have happened: * switching to java 8 / maven 3.5 * switching to servlet 3.1 / jsp 2.3 (i.e. tomcat 8.5+) * haddock as default template (renaming 2.10 default template to "210") * begin to move to a multi-module build (right now, the css, js, jsp stuff is on the war module, with all the java files on there on their own -main- module, but I expect to begin to break it in smaller modules somewhere soon) * a handful of backwards incompatible changes regarding classes moved from package, method with different signatures, etc. As for the build, there's a Jenkins build on ASF infrastructure at [#1], which should be always green/blue. This build also triggers a Sonar analysis, reachable at [#2], which right now is only informative. Finally, as for the JIRA issues, I'm not the best one to say, because I still have it pending to do with latest commits on master, but it'd help a lot: people go there to see what is contained on each release, helps to see on what you're working, etc. don't know if I'm leaving something, but HTH juan pablo [#1] https://builds.apache.org/blue/organizations/jenkins/jspwiki/activity [#2] https://builds.apache.org/analysis/overview?id=org.apache.jspwiki%3Ajspwiki-builder On Sun, Nov 11, 2018 at 8:58 PM Murray Altheim <murra...@altheim.com> wrote: > Hi, > > I'm just starting again, rebuilding my dev environment for JSPWiki. I'm > running Eclipse JEE version 2018-09 with Java 8 (Oracle 1.8.0_172). > I imported the entire 'develop' tree off of the GIT repository, and found > 23 compile errors (actually 4 unique), namely: > > att cannot be resolved in AttachmentTab.jsp > BASE_URL cannot be resolved or is not a field in Install.jsp > searchref cannot be resolved in AJAXSearch.jsp > web.xml is missing and <failOnMissingWebXml> is set to true > in pom.xml > > My questions are: > > 1. should I be developing (adding plugins, etc.) in the 'develop' branch, > or somewhere else? I didn't see a 2.10.x branch. I'm assuming we don't > work against 'master' (?). Or should I begin working in a new branch? > > 2. are the above errors actually in the branch or are they a product of > some error in my configuration? I'm kinda assuming the latter since > I'm guessing we don't normally leave the build broken... > > I've set up JDK 1.6 as I see the parent POM uses 1.6 but this didn't > have any effect on the above-described compile errors. > > > 3. There's a dev note that states all work should be done against a JIRA > issue. Is this true of greenfield (new plugin) work as well? I.e., > should I/we be creating a JIRA item for this work? > > 4. Where can I find any road map info on migration to more current > versions of Java 8, as well as various libraries? > > While my plugins aren't (to my memory) version-dependent, I'm working > on several providers, where many of the classes require Java 7's > "try-with-resources" feature and several requires Java 8, e.g., the > ability to refer to interface static methods (this is a requirement > of one of my core dependencies, not my owh code), so this would be my > highest priority (rather than re-write those classes for an EOL'd Java > or abandon the dependency, which would cripple the project). > > 5. Any other advice on getting set up properly so I don't bork the > build accidentally. > > Cheers, > > Murray > > ........................................................................... > Murray Altheim <murray18 at altheim dot com> = = === > http://www.altheim.com/murray/ === > === > = = === > In the evening > The rice leaves in the garden > Rustle in the autumn wind > That blows through my reed hut. > -- Minamoto no Tsunenobu > > > >
