At the risk of saying something about doing something that's already been done, I'm going to do it anyway.
To me, the points raised seem like good and appropriate ones. To that end then, it seems like a list of those things that might be required for a move to 4.0 should be made and then a plan for working actively toward addressing that list. * Angular Circ going mainstream * Merging OpenSRF into Evergreen * Removal of any XUL client / DoJo elements after update to Angular JS/Angular * Addressing remaining staffcatblocker tagged LP reports With all of that to also say, moving from 1.xx series to 2.xx series wasn't as seachanging as 2.xx to 3.xx. I'm not sure that 3.xx to 4.xx needs to be a complete seachange either. - Ruth On Wed, Jul 9, 2025 at 12:30 PM Shula Link via Evergreen-dev < [email protected]> wrote: > I'm going to agree with Chris, Jeff, and Jane on this; 3.x to 4.x should > mark as big of a shift in Evergreen as the move from 2.x to 3.x did. > > Shula Link (she/her) > Systems Services Librarian > Greater Clarks Hill Regional Library > [email protected] > 706-447-6702 > > > On Wed, Jul 9, 2025 at 11:08 AM Chris Sharp via Evergreen-dev < > [email protected]> wrote: > >> As a user/admin, yes, I would expect a major version release (e.g. 4.X) >> to be different enough to merit the new classification. I agree with Jeff >> and Jane that removal of legacy frameworks and moving to Angular for the >> remaining AngJS UIs would suffice. Definitely merging OpenSRF into >> Evergreen would qualify too. Maybe those are the goals we should strive >> for? I'm in favor of the next release remaining in the 3.X series. >> >> On Wed, Jul 9, 2025 at 10:18 AM Terran McCanna via Evergreen-dev < >> [email protected]> wrote: >> >>> I also recognize that the numbering is arbitrary, but there is >>> definitely something about shifting from the 3 series to the 4 series that >>> implies a bigger change. My preference would be to wait until Angular Circ >>> is ready because that will be a more visible and dramatic change and really >>> mark the end of the initial web client push. >>> >>> There are still 7 bugs with the staffcatalogblocker tag - if we can wrap >>> those up, then 4.0 could mark the complete and utter end of the old >>> embedded TPAC staff catalog for those libraries that have been unable to >>> make the switch. (I believe the work in progress bugs relating to hold >>> groups and shelving location groups have been the biggest sticking points.) >>> >>> Another more visible change could be the Bootstrap KPAC that I am nearly >>> done with. That could go into 3.next, but it could also wait for 4.0 to >>> make it a bigger release. >>> >>> >>> On Tue, Jul 8, 2025 at 7:22 PM Jeff Davis via Evergreen-dev < >>> [email protected]> wrote: >>> >>>> We've been talking about calling our next major release Evergreen 4.0, >>>> rather than 3.16. >>>> >>>> Is there a list of features that we want to include in a 4.0 release? >>>> Should we hold off on bumping the version number to 4.0 until those >>>> features are ready? >>>> >>>> Some candidates for "features that warrant going to 4.0": >>>> - Making Angular circ the standard circ UI, rather than experimental. >>>> My understanding is that we don't expect that to happen in the next >>>> release. >>>> - Merging OpenSRF into Evergreen (LP#2032835). We were waiting to >>>> replace ejabberd with Redis before doing that; Redis is now supported in >>>> Evergreen, but I don't know if anyone has revisited merging OpenSRF into EG >>>> since then. >>>> - There are a number of bugs targeted to "4.0-beta" in Launchpad, but >>>> AFAIK they are just targeting the next major release, whether it's called >>>> 4.0 or not. >>>> >>>> Any opinions? I would prefer to reserve "4.0" for a release that is >>>> somehow "more" than just the next major release, but I recognize that >>>> version numbering is basically arbitrary. >>>> -- >>>> Jeff Davis >>>> BC Libraries Cooperative >>>> _______________________________________________ >>>> Evergreen-dev mailing list -- [email protected] >>>> To unsubscribe send an email to >>>> [email protected] >>>> >>> _______________________________________________ >>> Evergreen-dev mailing list -- [email protected] >>> To unsubscribe send an email to >>> [email protected] >>> >> >> >> -- >> >> [image: logo with link to Georgia Public Library Service website] >> <https://georgialibraries.org/> >> >> Chris Sharp, PINES System Administrator >> >> ------------------------------ >> >> Georgia Public Library Service >> >> 2872 Woodcock Blvd, Suite 250 | Atlanta, GA 30341 >> >> (404) 235-7147 | [email protected] >> >> [image: logo with link to Georgia Public Library Service Facebook page] >> <https://www.facebook.com/georgialibraries>[image: logo with link to >> Georgia Public Library Service Instagram page] >> <https://www.instagram.com/georgialibraries/>[image: logo with link to >> Georgia Public Library Service LinkedIn page] >> <https://www.linkedin.com/company/georgia-public-library-service/>[image: >> logo with link to Georgia Public Library Service Threads page] >> <https://www.threads.net/@georgialibraries> >> >> Join our email list <http://georgialibraries.org/subscription> for >> stories of Georgia libraries making an impact in our communities. >> _______________________________________________ >> Evergreen-dev mailing list -- [email protected] >> To unsubscribe send an email to >> [email protected] >> > _______________________________________________ > Evergreen-dev mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ Evergreen-dev mailing list -- [email protected] To unsubscribe send an email to [email protected]
