Correct. We definitely do not want to be changing the REST URLs with each minor update of the module.
-Burke On Tue, May 15, 2012 at 10:13 PM, Spencer Kathol <spen...@kathol.net> wrote: > Darius, Roger, and Whoever, > > I wanted to clarify the difference between module and API versions. Based > on the conversation, I think (and would like to confirm) the v1 part of the > URL (and Java package) will stay the same as the module advances to 1.1, > 1.2... This is helpful to know since I'm working on a ticket to expose > provider objects for v1.1. > > The 2.x module versions will add functionality, nested under /rest/v2... > > > Thanks, > > -Spencer > > > On 5/15/2012 5:57 PM, Darius Jazayeri wrote: > > Roger, > > To clarify, I do *not* think we should have branches of the > webservices.rest module for OpenMRS 1.8.x, 1.9.x, 1.10.x, etc. I assume > that we will release webservices.rest v1.0, and this will work with OpenMRS > 1.8.2+. However if you're using OpenMRS 1.9 with webservices.rest v1.0 you > will not have access to anything that wasn't available in OpenMRS 1.8 (e.g. > Visits, Location Attributes) I think we should do a > "webservices.rest-19ext" module that adds support for all the new 1.9 > features. > > My initial thought is that adding new fields to existing resources (e.g. > adding attributes to Location) should not increment the version number of > the REST API. (But this is not well-thought out.) > > Regarding whether to release 1.0 or not. I feel very strongly that we > should release 1.0 ASAP, with the current functionality. > > Almost a year ago we set out a limited set of functional requirements: > we wanted to satisfy a few key user stories that were suggested by > interested people. (See this wiki page <https://wiki.openmrs.org/x/94IHAQ>.) > We added to that the strategic requirement that whatever we release as > "1.0" should be an API that we want to support going forwards. > > As a result of that requirement we delayed doing a 1.0 release to make > some fundamental design changes. (The bulk of these were spurred by you, > Roger, because you insisted we deal with the issue of subclasses. I think > you were absolutely right to do that, and I think it led to us doing some > very-necessary refactoring of the code. So, a non-sarcastic "Thanks" for > that.) > > At this point I really think we need release our current code (just > missing a couple of reviews) as 1.0, and commit to supporting it. Work can > and should continue to happen on the module. It is straightforward to add > some missing resources and release 1.1, 1.2, etc. (For the record those > would be *module* versions, *not* API versions.) > > -Darius > > PS- Regarding competition of resources between finishing off the 1.8 API > and doing the 1.9 API...I'd say "patches are welcome". Whatever tickets > people create and vote on, and whatever tickets people claim and submit > patches to, is what will get released first. :-) > > On Tue, May 15, 2012 at 3:21 PM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < > r...@cdc.gov> wrote: > >> We have not had an up-to-date version of RESTWS in the module repo >> for quite a while, and there have been a lot of important changes. Darius >> would like to get something into the repo, and I agree, but I don't think >> the current version is sufficiently complete and correct to just move on. >> I have four reasons for this: (1) we don't have all the 1.8 data model in >> REST; (2) we have some known anomalies to fix; (3) we haven't had much >> experience with the subclass model; and (4) there will be a competition for >> resources due to the need for a version that supports the 1.9 data model. >> >> >> >> If I understand Darius correctly, he never thought version 1.0 would >> be a complete exposure of the data model, but only a sufficient proof of >> concept to assure that the interface would not change drastically. But I >> believe everyone who has tried to use RESTWS has found a data object they >> needed which was not exposed. If a needed object is not exposed, then the >> user can't really put RESTWS to the test. I don't really care what the >> 1.8-compatible and the 1.9-compatible releases are called, I just want a >> clear path to a fully capable 1.8-compatible version. I don't want issues >> (1)-(3) to be lost as we pursue 1.9. >> >> >> >> It is not clear how we are going to revise RESTWS as the data model >> changes. If I understand Darius correctly, the "v1.0" portion of the URL >> will indicate that the module supports 1.8, and will be changed to another >> value (most likely "v2.0") when the module supports 1.9. There will >> probably not be much backporting (maybe additional queries or custom reps >> or a resource-specific catalog call) because most of the changes will >> depend on the data model (in the case of 1.8-1.9, location attributes, >> providers, provider attributes, visits, multiple providers per encounter, >> concept mapping, complex concepts). It seems to make sense to make a new >> 2.0 head and keep a 1.0 branch, but I don't think we've ever worked on both >> a branch and the head at the same time. So I think it would be better to >> get 1.0 to a more complete, correct state before we start work on 2.0. >> >> >> >> Maybe the sprint schedule needs to be revised to have an RESTWS 1.1 >> (or whatever) sprint sooner, and tickets that address 1.9 issues should be >> given a new future release fix 2.0 (or whatever). Maybe we can have >> simultaneous 1.1 and 2.0 sprints. >> >> >> >> >> >> >> ------------------------------ >> Click here to >> unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list > > > ------------------------------ > Click here to > unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > > ------------------------------ > Click here to > unsubscribe<lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list > _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
