Darius, So if I understand you correctly, you are saying that we will release v1.0 of the module the way it is currently with support for OpenMRS 1.8.1 and higher. Then we will release v1.1 of the module (that will require OpenMRS 1.9 and higher) that will be compatible with OpenMRS 1.9, but you do not want branches for the module?? Or v1.1 will still support 1.8 and we will have another module that will provide 1.9 resources??
--- Regards, Saptarshi PURKAYASTHA My Tech Blog: http://sunnytalkstech.blogspot.com You Live by CHOICE, Not by CHANCE On 16 May 2012 05:27, Darius Jazayeri <djazayeri+...@gmail.com> 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 > > > _________________________________________ 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]
