New core release

[zerocrates]

Due to the updated dependencies and module change requirements it's probably clearest to call this 2.0.

August 7 target.

[Daniel-KM]

Fine, it's a good thing. Not sure about the numbering, but it doesn't matter.

Do you think you will review all the old and less old pull requests at the same time? Some features that can be included in the next version:

• root site, sub domain management, sites without /s/ or /page/ (Subdomains and domain mapping #331 (2015), Main and additional sites #870, etc. and various other threads in the forum. Because it may break the routing system, it's a good opportunity to include it in version 2).
• PSR messages (Added a way to use psr-3 messages. #1372, for non-american sites)
• easyrdf (Upgrade/easyrdf #1335, important to import not-so-big vocabularies)
• gulp (Feature/gulp module #1159, in particular to release modules)
• various new variables to query the api (item has media, and media type, created date, etc. : see modules AdvancedSearchPlus and Next), but not sure if the api should manage all the cases

Thanks for all!

[zerocrates]

On the numbering it's primarily there to enforce user upgrades of modules because of the Doctrine-related change (as mentioned on the forums). Note this will generally apply to modules with ^1 type Omeka S version requirements declared in their INI files, which is most of them. So ones that don't need to change may need a very simple release just declaring that they work with version 2 also, like ^1.1.0 || ^2.0.0.

I will look at the PRs, yes.

[hxsllc]

Very interested in the ability to remove /s/digital from the "default" site, and have a domain mapped to the default site.

John you may be aware of this:
https://github.com/hafizchin/OmekaSDomainManager

It works, but it conflicts with Daniel's CleanURL, which is also more or less a requirement for any serious digital library that wants to provide something approaching a permanent URL / permalink.

Example:
http://edisondigital.rutgers.edu/s/digital/page/welcome

should be >
http://edisondigital.rutgers.edu

Example:
http://edisondigital.rutgers.edu/s/digital/item?page=1&sort_by=dcterms%3Aidentifier&sort_order=asc

should allow for reverse sort in site settings >
http://edisondigital.rutgers.edu/item

Example:
http://edisondigital.rutgers.edu/s/digital/item/154520

is better as >
http://edisondigital.rutgers.edu/s/digital/document/0915X018C9
but really should be
http://edisondigital.rutgers.edu/item/0915X018C9 << PURL-style

If all of these use cases could be handled in core rather than plugin, that's ideal. But I think the most critical one is to remove /s/sitename from the default site, which allows existing CleanURL plugin to do what it already does. Domain mapping to a particular site is also very useful, but perhaps doesn't pass the threshold for decision to include in core. At least by removing /s/sitename, the default site could "become" the domain if core is installed in the root web directory of the domain.