[Archivesspace_Users_Group] ArchivesSpace v2.6.0 now available

[Christine Di Bella]

ArchivesSpace is announcing the availability of v2.6.0. You can download it at 
https://github.com/archivesspace/archivesspace/releases/tag/v2.6.0.

This release contains program-led and community pull requests that provide 
feature enhancements, bug fixes, infrastructure improvements and documentation 
updates. There are a number of small changes to the staff and public interfaces 
to improve usability and clarity. There is also a significant revamp of how 
background jobs run, including a new reports page layout. This release also has 
a new feature guided by a community-initiated and authored specification, the 
option to generate human-readable URLs for use in the public user interface. A 
full list of the changes and improvements is provided on the release page.

Thanks very much to community members Br. Paul, Blake Carver, Mark Cooper, Tim 
DiLauro, Bobbi Fox, Brian Harrington, dvhassel, Adam Jazairi, Steve Majewski, 
Dave Mayo, Curtis Poston, Austin Schaffer, and Trevor Thornton for their code 
contributions to this release. Thanks also to the contract developer we have 
been able to engage through member funds, Manny Rodriguez (via LibraryHost), 
for his substantial efforts on the human-readable URLs feature. Thanks as 
always to LYRASIS Digital Technology Services for their technical support. This 
release is also very much a testament to the efforts of our Development 
Prioritization sub-team, Testing sub-team, Technical Documentation sub-team, 
and Core Committers Group, as well as individual ArchivesSpace users like Celia 
Caust-Ellenbogen, Cory Nimer, and Rachel Searcy, who identified and helped us 
work through particular bug fixes and new features in this release.

Within the program, our co-op student Sarah Morrissey did amazing work in 
providing a number of community-requested improvements to the staff and public 
interfaces (many of them recommended by the Staff Interface Enhancement Working 
Group last year). And though I don't always call them out in release 
announcements, I would be remiss if I didn't mention that Technical Lead Laney 
McGlohon and Junior Developer Lora Woodford worked through a tremendous amount 
of their own code and that of others to bring this packed release to you. We 
are very fortunate to have such a wonderful community-based and user-focused 
developer team.

Information on upgrading to a new version of ArchivesSpace is available at 
http://archivesspace.github.io/archivesspace/user/upgrading-to-a-new-release-of-archivesspace/.
 If you have not yet upgraded to a recent version, we recommend going directly 
to 2.6.0. Please note that a complete reindex is required for this release.

Please let us know if you have any questions or need help upgrading. We are 
turning our attention to some needed infrastructure improvements for the 
application, but also aim for some work on agents and recording language 
information that will make ArchivesSpace more standards-compliant in these 
areas to be ready to go into the application in a release later this summer. 
We'll be updating the roadmap on the wiki in the next few days.

Christine

Christine Di Bella
ArchivesSpace Program Manager
christine.dibe...@lyrasis.org
800.999.8558 x2905
678-235-2905
cdibella13 (Skype)

[ASpaceOrgHomeMedium]

___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Working with multiple ASpace strings

[Rees, John (NIH/NLM) [E]]

Thank you.

As usual, it’s the nervous-human equation that is the most confounding when 
embarking on major technological change.

Namaste,
John


From: Kevin Clair 
Sent: Thursday, May 30, 2019 8:32 AM
To: Archivesspace Users Group 
Subject: Re: [Archivesspace_Users_Group] Working with multiple ASpace strings

At Denver we have one less environment than Dartmouth, and our ArchivesSpace is 
hosted so our development environment tends to only gets its data synced with 
production when new releases come out, but otherwise we do what Joshua does.  -k

From: 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 on behalf of "Joshua D. Shaw" 
mailto:joshua.d.s...@dartmouth.edu>>
Reply-To: Archivesspace Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Date: Thursday, May 30, 2019 at 6:12 AM
To: Archivesspace Group 
mailto:archivesspace_users_group@lyralists.lyrasis.org>>
Subject: Re: [Archivesspace_Users_Group] Working with multiple ASpace strings

We've got three (well four if you count my local dev) environments and follow a 
pretty strict process of data always goes from prod -> other environments via a 
db clone and code always pushes up via local->dev->pre-prod->prod with varying 
degrees of QA along the way. We also QA integrations the same way. I typically 
clone the production data before any QA process to ensure that the QA 
environment is as close to prod as possible. Long story short... we follow a 
hybrid of #1 & #3. Tests of code changes & representative data in QA and then 
full runs in production.

Hope that helps!
Joshua


From: 
archivesspace_users_group-boun...@lyralists.lyrasis.org
 
mailto:archivesspace_users_group-boun...@lyralists.lyrasis.org>>
 on behalf of Rees, John (NIH/NLM) [E] 
mailto:re...@mail.nlm.nih.gov>>
Sent: Wednesday, May 29, 2019 11:43 AM
To: 
archivesspace_users_group@lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Working with multiple ASpace strings


Hi all,



This question isn’t aspace-centric, but for those of you that have multiple 
deployment strings (dev, qa, production) and that use the PUI, what is your 
best practice for entering new data or massaging existing data?



  1.  Do you test load/edit in QA then re-run the job in production?
  2.  Or do you load/edit in QA and replicate/auto-deploy to production? Can 
you just copy the database and re-index?
  3.  Not agonize over mistakes and just do it all in production?
  4.  Something else?



Do you worry about keeping the strings in synch?



Our old process was like #1, but we had separate systems for generating EAD and 
public facing search/discovery. With Aspace we are adding additional customers, 
more data types, less user command/control, etc. Is there a sweet spot for 
ensuring data integrity but have non-burdensome and flexible workflows?



John





John P. Rees

Archivist and Digital Resources Manager

History of Medicine Division

National Library of Medicine

301-827-4510










___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Working with multiple ASpace strings

[Kevin Clair]

At Denver we have one less environment than Dartmouth, and our ArchivesSpace is 
hosted so our development environment tends to only gets its data synced with 
production when new releases come out, but otherwise we do what Joshua does.  -k

From:  on behalf of 
"Joshua D. Shaw" 
Reply-To: Archivesspace Group 
Date: Thursday, May 30, 2019 at 6:12 AM
To: Archivesspace Group 
Subject: Re: [Archivesspace_Users_Group] Working with multiple ASpace strings

We've got three (well four if you count my local dev) environments and follow a 
pretty strict process of data always goes from prod -> other environments via a 
db clone and code always pushes up via local->dev->pre-prod->prod with varying 
degrees of QA along the way. We also QA integrations the same way. I typically 
clone the production data before any QA process to ensure that the QA 
environment is as close to prod as possible. Long story short... we follow a 
hybrid of #1 & #3. Tests of code changes & representative data in QA and then 
full runs in production.

Hope that helps!
Joshua


From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of Rees, 
John (NIH/NLM) [E] 
Sent: Wednesday, May 29, 2019 11:43 AM
To: archivesspace_users_group@lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Working with multiple ASpace strings


Hi all,



This question isn’t aspace-centric, but for those of you that have multiple 
deployment strings (dev, qa, production) and that use the PUI, what is your 
best practice for entering new data or massaging existing data?



  1.  Do you test load/edit in QA then re-run the job in production?
  2.  Or do you load/edit in QA and replicate/auto-deploy to production? Can 
you just copy the database and re-index?
  3.  Not agonize over mistakes and just do it all in production?
  4.  Something else?



Do you worry about keeping the strings in synch?



Our old process was like #1, but we had separate systems for generating EAD and 
public facing search/discovery. With Aspace we are adding additional customers, 
more data types, less user command/control, etc. Is there a sweet spot for 
ensuring data integrity but have non-burdensome and flexible workflows?



John





John P. Rees

Archivist and Digital Resources Manager

History of Medicine Division

National Library of Medicine

301-827-4510










___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group

Re: [Archivesspace_Users_Group] Working with multiple ASpace strings

[Joshua D. Shaw]

We've got three (well four if you count my local dev) environments and follow a 
pretty strict process of data always goes from prod -> other environments via a 
db clone and code always pushes up via local->dev->pre-prod->prod with varying 
degrees of QA along the way. We also QA integrations the same way. I typically 
clone the production data before any QA process to ensure that the QA 
environment is as close to prod as possible. Long story short... we follow a 
hybrid of #1 & #3. Tests of code changes & representative data in QA and then 
full runs in production.

Hope that helps!
Joshua


From: archivesspace_users_group-boun...@lyralists.lyrasis.org 
 on behalf of Rees, 
John (NIH/NLM) [E] 
Sent: Wednesday, May 29, 2019 11:43 AM
To: archivesspace_users_group@lyralists.lyrasis.org
Subject: [Archivesspace_Users_Group] Working with multiple ASpace strings


Hi all,



This question isn’t aspace-centric, but for those of you that have multiple 
deployment strings (dev, qa, production) and that use the PUI, what is your 
best practice for entering new data or massaging existing data?



  1.  Do you test load/edit in QA then re-run the job in production?
  2.  Or do you load/edit in QA and replicate/auto-deploy to production? Can 
you just copy the database and re-index?
  3.  Not agonize over mistakes and just do it all in production?
  4.  Something else?



Do you worry about keeping the strings in synch?



Our old process was like #1, but we had separate systems for generating EAD and 
public facing search/discovery. With Aspace we are adding additional customers, 
more data types, less user command/control, etc. Is there a sweet spot for 
ensuring data integrity but have non-burdensome and flexible workflows?



John





John P. Rees

Archivist and Digital Resources Manager

History of Medicine Division

National Library of Medicine

301-827-4510










___
Archivesspace_Users_Group mailing list
Archivesspace_Users_Group@lyralists.lyrasis.org
http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group