-
Notifications
You must be signed in to change notification settings - Fork 13
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Created
date for published versions is updated to the date of publishing
#2075
Comments
Could you say more about why this is your expectation? I'll break this down into parts so I can ask some more focused questions. First, why would you expect the created date for "all published versions" to be the same? A published version is only created upon publishing the Dandiset, which means each published version should feature a created date matching the date it was published (e.g., the date that appears in the published version number). Second, why would you expect the draft version's created date to change at all? Actually, I may know the answer to this one: are you thinking of the draft version of the Dandiset as something that becomes the published version, leading to the creation of a new draft version to work on? Our model differs from that: we consider the draft version to be a sort of permanent companion to the Dandiset; it is created when the Dandiset is created, and published versions are created independently "from" it. Under this model, the draft version is indeed created only once, then lives a long life spawning published versions, but never undergoing the sort of change that would necessitate new draft versions being created. My other broad question is: what problems did this mismatch in expectations cause for you specifically? I want to figure that out because changing the model will have subtle effects that may cause bugs. We may be leaking implementation details into the interface in a way that is not helpful, but in that case, I'd want to explore alternative ways of displaying this date data in the DLP. |
me too. Whether Moreover, as "published" version is published once and should never change, having both "Created" and "Modified" to correspond to the same date gives 0 extra bytes of information and thus questions rationale of having it there. While presenting the date when dandiset was created is exposing the life cycle of the dandiset (created X months ago, this version published Y months after). The correct date is already present in the metadata which is associated with that dandiset: ❯ curl --silent -X 'GET' 'https://api.dandiarchive.org/api/dandisets/000130/versions/0.241017.1448/' -H 'accept: application/json' | jq .dateCreated
"2021-08-21T19:29:11.649012+00:00" hence the fact that DLP uses some other date (when the "model" for that release was created... not really corresponding in semantics to "when dandiset was created") is just adding confusion to the user would would be finding correct date in the metadata. Hence I think this is indeed a UX shortcoming and should be addressed. |
Description
When a Dandiset has published versions the
Created
date on the DLP for a published version is updated to the date that the published version was created. For example, see Dandiset 000130 which is shown below.Draft version
Published version - January 12, 2022
Expected behavior
I would expect that the
Created
date should be the same for all published versions and theDraft
version.The text was updated successfully, but these errors were encountered: