Did Kirk's note about package renaming make the M3 scope? I think it would be 
great to start Geode's 1.0 on a consistent naming standard.
:)

Pro-Geode!!!
Brian -

Sent from my iPhone

> On May 3, 2016, at 6:09 PM, Anthony Baker <[email protected]> wrote:
> 
> William,
> 
> What do you think about including these in M3?
> 
> GEODE-612    Update Jackson version since current version is not on Maven 
> central
> GEODE-1028    Broken website link
> GEODE-1191 HDFS references
> GEODE-1133 SeparateClassloaderTestRunner
> GEODE-1260 Source distribution version info
> 
> Anthony
> 
> 
>> On May 3, 2016, at 3:49 PM, William Markito <[email protected]> wrote:
>> 
>> Guys, restarting this thread to get a discussion going about M3, 1.0.0 and
>> next -  As the release manager for M3 here is what I'd like to propose.
>> 
>> Any feedback is welcome and let's also reuse this thread to talk a little
>> bit about roadmap as well ?
>> 
>> # Current M3 Scope (
>> https://cwiki.apache.org/confluence/display/GEODE/1.0.0-incubating.M3+Release
>> )
>> 
>> GEODE-33
>> GEODE-823
>> GEODE-835
>> GEODE-919
>> GEODE-1146
>> GEODE-1168
>> GEODE-1203
>> GEODE-1259
>> GEODE-1278
>> GEODE-1293
>> GEODE-1316
>> GEODE-1256
>> GEODE-1267
>> 
>> == Proposed scope & roadmap ==
>> 
>> I'd like to breakdown the release a little bit and already start planning
>> the next releases.
>> 
>> # Geode 1.0.0-incubating M3
>> 
>> GEODE-1316 Update @since tags to include GemFire or Geode in the version
>> name
>> GEODE-1293 Align code and docs for modules
>> GEODE-1278 AbstractPeerTXRegionStub should throw
>> TransactionDataNodeHasDeparted when remote cache is closed
>> GEODE-1267 NOTICE file improvements
>> GEODE-1256 Geode website - Unapproved licenses
>> GEODE-1203 gfsh connect --use-http reports a ClassNotFoundException
>> GEODE-919 GEODE-823 Remove checksums from .asc files (asc.md5, asc.sha1)
>> GEODE-835 Replace joptsimple source with a binary dependency
>> GEODE-823 RC Feedback: Fix build artifacts
>> GEODE-33-1 Create project examples
>> 
>> # Geode 1.0.0-incubating
>> 
>> GEODE-33-2 Create project examples
>> GEODE-1331 gfsh.bat on Windows is incorrect
>> GEODE-1168 geode-dependencies manifest is missing jars that are present in
>> the lib directory
>> GEODE-629 Replace use of org.json with Jackson JSON library
>> GEODE-607 the offheap package needs better unit test coverage
>> GEODE-136 Fix possible NullPointerException in Gfsh's 'list regions'
>> command's GetRegionsFunction.
>> 
>> # Geode 1.X.0-incubating
>> 
>> GEODE-17 Provide Integrated Security
>> GEODE-11 Lucene Integration
>> GEODE-33-3 Create project examples
>> 
>> # Geode 2.0.0-incubating
>> 
>> GEODE-72 Remove deprecated APIs from Geode
>> GEODE-37 Package renaming
>> ---------------------------
>> 
>> Comments:
>> 
>> GEODE-33 would be broken into 3 different tasks, where on M3 we would start
>> with the example structure and a few examples, and incrementally add more
>> examples in the next releases.
>> 
>> GEODE-37 is the package rename which due to the huge effort in testing and
>> with the goal to complete the removal of deprecated API's (GEODE-72 and
>> it's sub-tasks) would be pushed to 2.0. This would also allow faster
>> releases in 1.0.0 series.
>> 
>> 
>> Thanks,
>> 
>> On Sun, May 1, 2016 at 9:24 AM, Niall Pemberton <[email protected]>
>> wrote:
>> 
>>>> On Fri, Apr 29, 2016 at 10:58 PM, Dan Smith <[email protected]> wrote:
>>>> 
>>>> I'm not sure if the docs are a prerequisite for graduation. I don't think
>>>> there are specific requirements about the level of documentation for
>>>> graduation, just about community involvement - which docs could help
>>>> encourage :)
>>> 
>>> I think this is a grey area with the user docs being on a vendor site.
>>> Theres a requirement that "every podling site sources should be maintained
>>> in the podling's site SVN or git directory"[1]. Clearly geode meets this to
>>> the letter of the law and I've seen other projects websites point to
>>> external resources that are useful. Since theres a plan to donate them at
>>> some point, my guess is it wouldn't be an issue.
>>> 
>>> [1] http://incubator.apache.org/guides/sites.html
>>> 
>>> 
>>> 
>>>> In any case we don't need to graduate or even be graduation ready to
>>>> release 1.0. The version number 1.0 has no special meaning to the ASF as
>>>> far as I can tell. But I think having regular releases and having an
>>>> official non-milestone release will help us grow the community.
>>> 
>>> A release without a milestone/alpha/beta qualifier is going to indicate
>>> this community thinks its ready for serious use - so while you're right
>>> from a ASF perspective, it will have a special meaning for the wider geode
>>> community. And while keeping the existing package names makes the
>>> transition easier for existing gemfire users, a package rename in a later
>>> version will add pain to the new vast(hopefully!) user base for geode. So I
>>> would say do it now rather than later.
>>> 
>>> However, if you're going to change the package name, then its also a good
>>> time to remove any deprecated features and correct/change any API's that
>>> you're not 100% happy with - which may be alot more work than just changing
>>> the package name.
>>> 
>>> Niall
>>> 
>>> 
>>>> 
>>>> This page has some information on what's required for graduation:
>>> http://incubator.apache.org/incubation/Incubation_Policy.html#Minimum+Graduation+Requirements
>>>> 
>>>> -Dan
>>>> 
>>>> 
>>>>> On Fri, Apr 29, 2016 at 2:28 PM, Dave Barnes <[email protected]> wrote:
>>>>> 
>>>>> We plan at some point to donate the docs so they'll be incorporated
>>> into
>>>>> the repo. Is this a prerequisite to graduating from incubation?
>>>>> 
>>>>>> On Fri, Apr 29, 2016 at 12:13 PM, Kirk Lund <[email protected]> wrote:
>>>>>> 
>>>>>> The package renaming would most likely break some backwards
>>>> compatibility
>>>>>> between 1.0 and 2.0. I'd prefer to see the packages get renamed
>>> before
>>>>> 1.0
>>>>>> so we can change the packages of Message classes, etc in the same
>>>> release
>>>>>> that introduces the new JGroups.
>>>>>> 
>>>>>> The packages are currently a mess of com.gemstone.*, com.vmware.*,
>>>>>> joptsimple.*, org.json.* (would we change all four or just the
>>>>>> gemstone/vmware packages?).
>>>>>> 
>>>>>> I'm probably biting off more than I should, but I'd be willing head
>>> up
>>>>> the
>>>>>> package renaming effort.
>>>>>> 
>>>>>> I think maintaining backwards compatibility (rolling upgrades
>>> included)
>>>>> for
>>>>>> releases following Geode 1.0 is a definite requirement. I'd like to
>>> see
>>>>> the
>>>>>> other discussion thread about defining the Geode protocol(s) converge
>>>>> with
>>>>>> this thread. Officially defining the communication protocols
>>> (cluster,
>>>>>> client/server, etc) would ideally happen in conjunction with 1.0 so
>>>> that
>>>>>> it's concrete and less ambiguous for 2.0 and later releases.
>>>>>> 
>>>>>> -Kirk
>>>>>> 
>>>>>> 
>>>>>> On Fri, Apr 29, 2016 at 11:59 AM, Dan Smith <[email protected]>
>>> wrote:
>>>>>> 
>>>>>>> We've been releasing milestones of 1.0, but at some point we
>>> actually
>>>>>> have
>>>>>>> to release a real geode 1.0 :)
>>>>>>> 
>>>>>>> What is keeping us from releasing geode 1.0 at this point? Just the
>>>>>> issues
>>>>>>> currently marked with Fix Version M3? I think we should nail down
>>> the
>>>>>> scope
>>>>>>> of 1.0 and track our progress to the 1.0 release.
>>>>>>> 
>>>>>>> From the apache process perspective, I don't think 1.0 is any
>>>> different
>>>>>>> from the milestone releases we've done so far. The only difference
>>>> with
>>>>>> 1.0
>>>>>>> is what it means to the geode community.
>>>>>>> 
>>>>>>> Gemfire maintained backwards compatibility with previous releases
>>> for
>>>>>>> persistent files, client/server, WAN, and P2P messaging. I think
>>> once
>>>>> we
>>>>>>> release 1.0 we should provide that same guarantee that the next
>>> geode
>>>>>>> release will be backwards compatible with 1.0.
>>>>>>> 
>>>>>>> We do still have the package renaming (GEODE-37) on the horizon. My
>>>>>>> suggestion is that in the interests of getting 1.0 out the door, at
>>>>> this
>>>>>>> point we should just release geode 1.0 with the old packages and
>>>> rename
>>>>>>> packages in geode 2.0.
>>>>>>> 
>>>>>>> Thoughts?
>>>>>>> 
>>>>>>> -Dan
>> 
>> 
>> 
>> --
>> 
>> ~/William
> 

Reply via email to