SIPServer should be packaged into releases

Chris makes a valid suggestion, but I disagree with it for a couple of reasons.

1. The SIPServer code is written in such a way that it remains compatible with a broad range of Evergreen releases. It typically checks the Evergreen capabilities before reporting/using the backend capabilities.

2. Changes to add new functionality to SIPServer more often than not end up requiring more changes to the Evergreen code than to the SIPServer code. In some cases, the functionality only need be added to Evergreen and SIPServer picks it up automatically.

I am not necessarily against doing SIPServer releases, but listing which versions of Evergreen a given SIPServer release is compatible with is a bit dicey. In principal, it is compatible with all releases of Evergreen. Some features will or won't be available depending on the Evergreen version. I think the latter is better documented in Evergreen with a note there if it also requires upgrading the SIPServer software to get the feature.

I would take the approach that we take with OpenSRF, in which OpenSRF's versioning scheme is completely Evergreen-agnostic. So SIPServer 1.3.1 (for an imaginary example) would be recommended/referred to by the version of Evergreen (like http://www.evergreen-ils.org/downloads.php where each version of Evergreen is matched to OpenSRF versions).

My contention is that you're running the SIP server from a specific HEAD in any case, even if you're rolling in changes constantly. Being able to refer to a tag on that particular head allows us to communicate to our libraries what's there and what's not in a way that's not as simple now.

Could the latest version of SIPServer tested to work with a particular version of Evergreen be included with Evergreen tarball releases? Perhaps that could eliminate the need for having separate version numbers for SIPServer.

Thing is, the latest SIPServer code is pretty much always backwards compatible with existing Evergreen releases. You should be able to run the current SIPServer code from Git against Evergreen 2.0 and up. You won't have all the features because the feature matrix depends on both.

To answer, Aleksey's question about packaging SIPServer with Evergreen in tarballs, I'd suggest he make that a wishlist bug on Evergreen, rather than on SIPServer. Mike Rylander is, I believe, the release manager for Evergreen 2.4, so it is really his decision on whether or not that happens for 2.4.

Another possibility is rolling SIPServer into Evergreen. We're not actually sharing the SIPServer code with Koha any more, and AFAIK, we're the only ones to use our particular SIPServer.

If we don't concern ourselves with Koha compatability for this or NCIPServer I'd be +1 for both of them being folded into Evergreen proper. (NCIPServer would probably need significant refactoring for that but it might be nice eventually.) I think as separate projects they don't see the attention they deserve.